Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

[Andreas Mohr]

Hi,

> On Thu, 2009-07-30 at 10:16 -0700, john stultz wrote:
> > Clocksources as modules was one of the initial design goals I had way
> > back. The benefit being that an older distro kernel could be made to
> > support newer stranger hardware via a clocksource driver. While the
> > hardware vendors have for the most part consolidated on HPET/ACPI PM
> > which has mostly avoided the need, I still think its worth preserving.
> 
> If the PIT case is a real use case for unregister than we can keep it
> around. If not, then that path just becomes unused and all unused code
> is open for removal from my perspective.
> 
> If the case you describe above is a good one, then someone eventually
> will add back the unregister path. Which should come with a good reason
> and with an actual user of the code..
> 
> Daniel

I'm still having a tendency towards unhappiness about my snd-azf3328
PCI soundcard driver and its new use of clock_event_device,
without a proper unload path existing (read: clock_event_device is the sole one
of about 7 different driver components - PCM, I2S, OPL3, MPU401, AC97 mixer,
joystick, ALSA sequencer timer / clock_event_device - which now suddenly
managed to prevent the driver from being unloadable for the first time
in its entire history) and not too many explanations as to how to
get this working optimally...

Would that be enough of a justification? ;-P

Plus [OT], would anyone perhaps have an explanation why I'm getting stalls
every couple seconds (probably a race between set_next_event() programming
the next value already and timer-related interrupt handling causing a
nearby trigger to get lost, but I don't know how to resolve this
- how do other drivers manage to handle this easily racey activity??).
BTW mouse interrupt activity does NOT manage to cancel these stalls.
This is especially noticeable during video playback.

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/