[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080731164658.GG26393@elte.hu>
Date: Thu, 31 Jul 2008 18:46:58 +0200
From: Ingo Molnar <mingo@...e.hu>
To: David Brownell <david-b@...bell.net>
Cc: Clemens Ladisch <clemens@...isch.de>,
lkml <linux-kernel@...r.kernel.org>, bob.picco@...com,
venkatesh.pallipadi@...el.com, Vojtech Pavlik <vojtech@...e.cz>,
the arch/x86 maintainers <x86@...nel.org>,
Adrian Bunk <bunk@...nel.org>
Subject: Re: [patch 2.6.27-rc1] /dev/hpet - fixes and cleanup
* David Brownell <david-b@...bell.net> wrote:
> From: David Brownell <dbrownell@...rs.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@...rs.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists