Re: [PATCH] Prevent clockevent event_handler ending up handler_noop

[Andreas Mohr]

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)

Or did I completely slide off the usual tracks of what is "politically
correct" to do with kernel source code here? ;)

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

I'm halfway through converting this driver, thus a not entirely negative
reply would be helpful...

See what such highres-deprived people as myself (PIT, acpi_pm,
_no_ HPET and thus no IRQed highres timer) are doing now,
PITy (sic!) my poor soul...

This timer could even be considered the predecessor of HPET,
since AFAIK several sound cards have such a feature
(maybe it's even semi-standardized?)
and thus it might be very worthwhile for tuning of rotten hardware.

And any hints on how to possibly (reliably!) provide both clock_event_device
(oneshot) _and_ clocksource for a _single_ IRQed countdown timer?

Thanks,

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/