[lkml]   [2003]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH][2.6][5/5]Support for HPET based timer

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
IO-APIC initialization is done. If HPET uses native mode, it cannot
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
processing, and thus we may end up getting inaccurate time (and
timer interrupts) in the kernel.

> -----Original Message-----
> From: Vojtech Pavlik []
> Sent: Tuesday, August 19, 2003 3:41 PM
> To: Pallipadi, Venkatesh
> Cc:;;
> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:1.651 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site