PM Timer as primary timing source on i386
RFC PATCH 1/1 PM Timer as primary timing source on i386
This patch implements support for a different timing source for the i386 architecture, the Power Management Timer (PMTMR). It offers correct results with a ~3.6MHz resolution even during aggressive Powermanagement like ACPI C-State transitions, throttling and/or frequency scaling. It is based partly on Arjan's patch for 2.4.
arch/i386/Kconfig | 10 + arch/i386/kernel/time.c | 1 arch/i386/kernel/timers/Makefile | 1 arch/i386/kernel/timers/timer_pm.c | 188 +++++++++++++++++++++++++++++++++++++ 4 files changed, 200 insertions(+)
arch/i386/Kconfig +10 -0
@@ -506,6 +506,16 @@ depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ default y +config X86_PM_TIMER + tristate "Use Power Management Timer (PMTMR) as primary timing source" + depends on ACPI_BUS + help + The Power Management Timer (PMTMR) is available on all + ACPI-capable systems. it provides a reliable timing source + which does not get affected by powermanagement features + (e.g. aggressive idling, throttling or frequency scaling), + unlike the commonly used Time Stamp Counter (TSC) timing source. + config X86_MCE bool "Machine Check Exception" ---help---
arch/i386/kernel/time.c +1 -0
@@ -81,6 +81,7 @@EXPORT_SYMBOL (i8253_lock);struct timer_opts *cur_timer = &timer_none; +EXPORT_SYMBOL (cur_timer);/* * This version of gettimeofday has microsecond resolution
arch/i386/kernel/timers/Makefile +1 -0
@@ -5,3 +5,4 @@ obj-y := timer.o timer_none.o timer_tsc.o timer_pit.o obj-$(CONFIG_X86_CYCLONE_TIMER) += timer_cyclone.o +obj-$(CONFIG_X86_PM_TIMER) += timer_pm.o
arch/i386/kernel/timers/timer_pm.c +188 -0
188 lines not on this page · raw message
Quoted 5 lines · Dominik Brodowski
This patch implements support for a different timing source for the i386 architecture, the Power Management Timer (PMTMR). It offers correct results with a ~3.6MHz resolution even during aggressive Powermanagement like ACPI C-State transitions, throttling and/or frequency scaling. It is based partly on Arjan's patch for 2.4.
Very cool! I had actually been working on a version of the same thing bug got stalled on the duplicated ACPI parsing. I like your trick of having it as a module to avoid the ACPI early boot parsing, but it could cause problems with alternate time sources. Maybe later in the 2.6/2.7 time frame we can do some sort of delayed registering and time selection.
I'll play around with it and let you know if I have any other feedback.
Very nice work!
-john