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

[Dominik Brodowski <linux@brodo.de>]

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