Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]

From: Dominik Brodowski
Date: Mon Oct 27 2003 - 14:02:48 EST


On Mon, Oct 27, 2003 at 10:42:34AM -0800, john stultz wrote:
> On Mon, 2003-10-27 at 10:24, Dominik Brodowski wrote:
> > On Mon, Oct 27, 2003 at 11:53:43PM +1100, Nick Piggin wrote:
> > > +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> > > + source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
> >
> > A few months ago, I proposed to make the ACPI "Powermanagement" timer, a
> > reliable timing source with ~3.6MHz resolution, available as a timer_opts
> > for arch/i386/kernel/timers/timer.c. [1]
> >
> > The major difficulty with this ACPI PM-Timer is that the I/O-port it is
> > located at is unknown during time_init.[2] So, it becomes necessary to use a
> > different timing source in the beginning, and switch to the ACPI PM-Timer
> > later.
> >
> > Here are two different methods to replace one timing source with another.
> > First, the simple (and buggy) one -- the timing is broken until the next
> > timer "tick" == the next call to mark_offset().
>
> Thanks for working on this, Dominik!
>
> My only comment is that rather then replacing the time source midstream,
> could we not do as the HPET time source does and use the late_time_init
> callback? That avoids the nasty time source switching code.

Because "late_time_init" is way too early. It might be usable for the
(unimplemented) detection method c) -- parsing the ACPI FADT ourselves --
described in the timer_pm.c code.
However, the currently used method uses struct acpi_fadt which is
filled in drivers/acpi/bus.c:acpi_bus_init(), which is called from
a subsys_initcall.

Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/