Re: [PATCH] Prevent clockevent event_handler ending up handler_noop

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 3 Sep 2008, Andreas Mohr wrote:
> Hi,
> 
> > This does not have any issue in normal case as most likely all the clockevent
> > devices are setup before the highres switch. But, can potentially be affecting
> > some corner case where HPET force detect happens after the highres switch.
> 
> So... does that apply to a nice sound card with an even nicer
> 1 MHz "DirectX timer" as well
> which I would soon force into registering a clock_event_device? ;)
> (I might add that this sound driver is _modular_, BTW it's azt3328.c)

Yup, the switchover to any new device can cause this. Right now we
only have HPET replacing PIT, but ..
 
> Or did I completely slide off the usual tracks of what is "politically
> correct" to do with kernel source code here? ;)

-ENOPARSE

> Oh, and how would this integrate (or rather, "conflict"?)
> with globally managed PIT / HPET event device handling?

Pretty much not. We have this global management as HPET replaces the
PIT and occupies the PIT irq as well, so we need to know which one is
active.

> See what such highres-deprived people as myself (PIT, acpi_pm,
> _no_ HPET and thus no IRQed highres timer) are doing now,

Err. PIT + acpi_pm works with highres. acpi_pm is a stable clocksource
and PIT is not a good, but a usable oneshot timer.
 
> And any hints on how to possibly (reliably!) provide both clock_event_device
> (oneshot) _and_ clocksource for a _single_ IRQed countdown timer?

No. For a reliable clocksource you need an ever increasing /
decreasing counter, which just wraps around when the max. count is
reached.

If you use a single shot timer, which is reprogrammed after every
interrupt, then you will deviate from the time line as you have no
idea how long it took from the counter reaching zero to the point
where you reload the timer. Simply wont work.

Thanks,

	tglx