From: Vojtech Pavlik <vojtech@suse.cz>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>,
linux-kernel@vger.kernel.org, torvalds@osdl.org, "Nakajima,
Jun" <jun.nakajima@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>
Subject: Re: [PATCH][2.6][5/5]Support for HPET based timer
Date: Wed, 20 Aug 2003 10:10:47 +0200 [thread overview]
Message-ID: <20030820081047.GD17793@ucw.cz> (raw)
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1902C7D1CE@fmsmsx405.fm.intel.com>
On Tue, Aug 19, 2003 at 06:28:40PM -0700, Pallipadi, Venkatesh wrote:
>
> 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.
Yes, that is a problem. We could do some switchover from PIT to HPET (or
from legacy to IOAPIC IRQs) after APICs are initialized, though I don't
like the idea very much. Best would be to remove the dependence on the
timer interrupt ticking so early. Or moving APIC detection earlier.
> 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.
Well, the APIC should have quite a number of free pins, which means that
the HPET shouldn't need to share an interrupt. Regarding lost and late
delivered timer interrupts - that happens nevertheless with drivers
disabling interrupts for a long time. The kernel timekeeping code can
cope with that.
> 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
> >
>
--
Vojtech Pavlik
SuSE Labs, SuSE CR
next prev parent reply other threads:[~2003-08-20 8:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-20 1:28 [PATCH][2.6][5/5]Support for HPET based timer Pallipadi, Venkatesh
2003-08-20 8:10 ` Vojtech Pavlik [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-08-21 20:56 Pallipadi, Venkatesh
2003-08-20 17:51 Pallipadi, Venkatesh
2003-08-21 8:25 ` Vojtech Pavlik
[not found] <mmGp.wp.3@gated-at.bofh.it>
[not found] ` <mnsM.1eL.13@gated-at.bofh.it>
[not found] ` <moRP.2r8.11@gated-at.bofh.it>
2003-08-20 0:31 ` Andi Kleen
2003-08-20 1:04 ` Jamie Lokier
2003-08-20 8:05 ` Vojtech Pavlik
2003-08-19 19:20 Pallipadi, Venkatesh
2003-08-19 22:41 ` Vojtech Pavlik
2003-08-20 0:08 ` Jamie Lokier
2003-08-20 8:03 ` Vojtech Pavlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030820081047.GD17793@ucw.cz \
--to=vojtech@suse.cz \
--cc=asit.k.mallick@intel.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.