Re: [patch 2.6.27-rc1] /dev/hpet - fixes and cleanup

[Ingo Molnar <mingo@elte.hu>]

* David Brownell <david-b@pacbell.net> wrote:

> From: David Brownell <dbrownell@users.sourceforge.net>
> 
> Minor /dev/hpet updates and bugfixes:
> 
>   * Remove dead code, mostly remnants of an incomplete/unusable
>     kernel interface ... noted when addressing "sparse" warnings:
>       + hpet_unregister() and a routine it calls
>       + hpet_task and all references, including hpet_task_lock
>       + hpet_data.hd_flags (and HPET_DATA_PLATFORM)
> 
>   * Correct and improve boot message:
>       + displays *counter* (shared between comparators) bit width,
>         not *timer* bit widths (which are often mixed)
>       + relabel "timers" as "comparators"; this is less confusing,
>         they are not independent like normal timers are (sigh)
>       + display MHz not Hz; it's never less than 10 MHz.
> 
>   * Tighten and correct the userspace interface code
>       + don't accidentally program comparators in 64-bit mode using
>         32-bit values ... always force comparators into 32-bit mode
>       + provide the correct bit definition flagging comparators with
>         periodic capability ... the ABI is unchanged
> 
>   * Update Documentation/hpet.txt
>       + be more correct and current
>       + expand description a bit
>       + don't mention that now-gone kernel interface
> 
> Plus, add a FIXME comment for something that could cause big trouble
> on systems with more capable HPETs than at least Intel seems to ship. 
> 
> It seems that few folk use this userspace interface; it's not very
> usable given the general lack of HPET IRQ routing.  I'm told that
> the only real point of it any more is to mmap for fast timestamps;
> IMO that's handled better through the gettimeofday() vsyscall.
> 
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> I CC'd everyone who MAINTAINERS says maintains HPET.  Odd to have
> four entries!!
> 
> And re that kernel interface ... IMO, worth having a relatively 
> generic interface for hardware timers instead of inventing a new 
> interface for each new bit of hardware.  Embedded systems tend to have 
> at least half a dozen timers to spare.

i've asked Clemens of how to merge this and we'll do it via 
tip/timers/hpet - so i queued it up there with the ACK of Clemens.

I also merged it up to latest -git. (the documentation bits already 
moved, etc.)

I suspect this is a 2.6.27 change, given its fix nature, but it will 
need some cooking in linux-next (via auto-timers-next) before this can 
be sent to Linus.

	Ingo