Re: [RFC][PATCH] x86_64: Fix collision between pmtimer and pit/hpet timekeeping

[Vojtech Pavlik <vojtech@suse.cz>]

On Wed, Dec 07, 2005 at 10:00:30AM -0800, john stultz wrote:
> On Wed, 2005-12-07 at 18:53 +0100, Andi Kleen wrote:
> > On Tue, Dec 06, 2005 at 09:00:39PM -0800, john stultz wrote:
> > > Hello,
> > > 	I thought I had caught all the problems when the no-legacy HPET support
> > > landed close to the time that the ACPI PM timer support landed, but
> > > apparently not. :(
> > > 
> > > On systems that do not support the HPET legacy functions (basically the
> > > IBM x460, but there could be others), in time_init() we accidentally
> > > fall into a PM timer conditional and set the vxtime_hz value to the PM
> > > timer's frequency. We then use this value with the HPET for timekeeping.
> > > 
> > > This patch (which mimics the behavior in time_init_gtod) corrects the
> > > collision.
> > > 
> > > Andi, any objections or suggestions for a better way?
> > 
> > Ok. I will apply it.
> > 
> > But I never quite got why you fall back to the PIT on these systems
> > anyways - if LEGSUP is not set it just means that the HPET interrupt
> > cannot be routed to irq 0, right? It should be quite easy to change
> > the timer code to accept timer interrupts on other irqs. 
> > 
> > You just need to allocate the other interrupt and possibly coordinate
> > that with the hpet char driver (or rather move the code for that
> > from there to time.c). I think implementing that would be a better
> > solution.
> 
> Indeed that does sound like a decent cleanup. I can't promise anything
> in the near future, but its on my list.
> 
> Would you then want to move all systems to use the non-legacy HPET
> interrupt?
 
Yes, that'd be very cool. The problem with doing it is that HPET is
initialized at a very early stage of boot where it isn't at all clear
which APIC pins will be free to take the HPET interrupt(s).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR