From: David Brownell <david-b@pacbell.net>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
bob.picco@hp.com, venkatesh.pallipadi@intel.com,
Vojtech Pavlik <vojtech@suse.cz>,
the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [patch 2.6.26] /dev/hpet - fixes and cleanup
Date: Wed, 23 Jul 2008 09:12:49 -0700 [thread overview]
Message-ID: <200807230912.49850.david-b@pacbell.net> (raw)
In-Reply-To: <4886E164.2070304@ladisch.de>
On Wednesday 23 July 2008, Clemens Ladisch wrote:
> David Brownell wrote:
> > * Tighten and correct the userspace interface code
> > ...
> > + only open comparators that have an interrupt, and can thus
> > perform "real work"
>
> This prevents userspace applications from doing mmap() on /dev/hpet
> even if there is no interrupt.
OK, I removed that ... HPET_IE_ON will already fail.
I didn't find any software using /dev/hpet, except for
the example in Documentation/hpet.txt ... presumably I
was looking in the wrong place. I'd surely have retched
at anything mmapping hardware registers though. ;)
> This seems to be the only part of the userspace interface that is
> used in practice. Because of the availability of POSIX timers, it might
> make sense to deprecate the HPET ioctl interface.
I'll leave that part up to someone else. If POSIX timers
are a sufficient userspace interface, great ... then that
mmap son't really be needed either! In fact, would the
/dev/hpet support even be needed? It's not very portable...
> > 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.
>
> AFAIK it was intended to be similar to the RTC callback interface, but
> that was before the generic high-precision timer stuff was introduced.
People seem to want access to the hardware backed timers too, and
not necessarily coupled to a task like the RTC stuff assumes. Folk
who want to drive that issue will need to sort out requirements...
the requests I've heard seem to focus on talking to kernel code.
But since HPET "timers" are really weak compared to what most embedded
platforms offer, I'm quite sure any API designed to its capabilities
would be underfeatured! Example, there are no external inputs (like
clocks or event pulses) or outputs (PWM or whatever) with HPET, and
likewise no flexibility about inputs (which internal clock, or maybe
external clocks).
- Dave
next prev parent reply other threads:[~2008-07-23 16:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-22 22:08 David Brownell
2008-07-23 7:44 ` Clemens Ladisch
2008-07-23 16:12 ` David Brownell [this message]
2008-07-23 16:50 ` David Brownell
2008-07-24 11:35 ` Clemens Ladisch
2008-07-25 19:55 ` David Brownell
2008-07-29 21:26 ` H. Peter Anvin
2008-07-25 19:58 ` [patch 2.6.26-git] " David Brownell
2008-07-28 7:57 ` Clemens Ladisch
2008-07-28 8:27 ` David Brownell
2008-07-28 9:10 ` Clemens Ladisch
2008-07-29 19:46 ` David Brownell
2008-07-29 19:47 ` [patch 2.6.27-rc1] " David Brownell
2008-07-31 16:46 ` Ingo Molnar
2008-07-31 16:55 ` Ingo Molnar
2008-07-31 19:59 ` David Brownell
2008-07-31 20:50 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200807230912.49850.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=bob.picco@hp.com \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.com \
--cc=vojtech@suse.cz \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome