RE: [PATCH][2.6][5/5]Support for HPET based timer

["Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>]

I experimented with HPET in native APIC routing mode. But, there 
are couple of issues in that space:

1) During boot up kernel expects to receive timer interrupt much before
the 
IO-APIC initialization is done. If HPET uses native mode, it cannot
generate 
timer interrupts till IOAPICs are initialized. So, we need to have some
sort of 
Workarounds in generic kernel to avoid dependency on timer interrupt
during the 
early boot.

2) More important question is, do we really want to share timer
interrupt with 
other PCI devices? This potentially can add some delay in the timer
interrupt 
processing, and thus we may end up getting inaccurate time (and
inaccurate 
timer interrupts) in the kernel.

Thanks,
-Venkatesh
> -----Original Message-----
> From: Vojtech Pavlik [mailto:vojtech@suse.cz] 
> Sent: Tuesday, August 19, 2003 3:41 PM
> To: Pallipadi, Venkatesh
> Cc: linux-kernel@vger.kernel.org; torvalds@osdl.org; 
> Nakajima, Jun; Mallick, Asit K
> Subject: Re: [PATCH][2.6][5/5]Support for HPET based timer
> 
> 
> On Tue, Aug 19, 2003 at 12:20:22PM -0700, Pallipadi, Venkatesh wrote:
> 
> > 5/5 - hpet5.patch - This can be a standalone patch. Without this
> >                     patch we loose interrupt generation capability
> >                     of RTC (/dev/rtc), due to HPET. With this patch
> >                     we basically try to emulate RTC interrupt
> >                     functions in software using HPET counter 1.
> > 
> 
> This is very wrong IMO. We shouldn't try to emulate the RTC interrupt
> for the kernel, instead the HPET should use native APIC interrupt
> routing. This way the RTC will keep working and the 'legacy mode' of
> HPET doesn't need to be used. I must admit I was a bit lazy when I was
> implementing the x86_64 variant and the native IRQ for HPET 
> is still on
> my to-do list.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs, SuSE CR
>