From: Henrique de Moraes Holschuh <hmh@debian.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
Pavel Machek <pavel@ucw.cz>, Stelian Pop <stelian@popies.net>,
Michael Hanselmann <linux-kernel@hansmi.ch>,
hdaps-devel@lists.sourceforge.net, lm-sensors@lm-sensors.org
Subject: Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)
Date: Wed, 5 Jul 2006 11:06:19 -0300 [thread overview]
Message-ID: <20060705140619.GB8452@khazad-dum.debian.net> (raw)
In-Reply-To: <1152086415.4995.0.camel@localhost>
On Wed, 05 Jul 2006, Johannes Berg wrote:
> > Also, there's a small issue with polling frequency. hdapsd needs a
> > fairly high frequency (say, 50Hz) to gather statistics and keep
> > response latency low, whereas the hdaps driver's internal polling
> > (routing to the input infrastructure) is currently done at only 20Hz.
> > We'll need to increase the latter, thereby slightly increasing system
> > load when hdaps isn't running.
>
> Note that with AMS we're better off -- it has two interrupts telling us
> when something is wrong.
>
> Hence, most of the discussion about loads of input values only applies
> to hdaps, the actual head-park functionality can be implemented with AMS
> without ever reading any sensor values.
>
> Hence we also need much less complexity in userland -- once an interrupt
> comes in we trigger the hd park...
Looks nice. For AMS, then, the userspace daemon can choose between deciding
for itself when to park heads using accel data, or to trust the firmware and
do it when told, or even to do both.
IBM *could* have done the same, since they already have an H8
microcontroller looking at that accelerometer :( Anyway, IMHO it would be
good to have AMS-like behaviour where the kernel driver exposes head-park
events to userspace in the generic interface.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
prev parent reply other threads:[~2006-07-05 14:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 12:48 Henrique de Moraes Holschuh
2006-07-04 7:59 ` Pavel Machek
2006-07-04 10:26 ` [Hdaps-devel] " Shem Multinymous
2006-07-04 10:57 ` Pavel Machek
2006-07-04 15:02 ` Thomas Tuttle
2006-07-05 3:13 ` Dmitry Torokhov
2006-07-04 16:23 ` Henrique de Moraes Holschuh
2006-07-04 23:57 ` Pavel Machek
2006-07-05 7:34 ` Vojtech Pavlik
2006-07-05 13:58 ` Henrique de Moraes Holschuh
2006-07-06 1:12 ` Pavel Machek
2006-07-05 7:59 ` [lm-sensors] " Jean Delvare
2006-07-05 8:00 ` [Hdaps-devel] " Johannes Berg
2006-07-05 14:06 ` Henrique de Moraes Holschuh [this message]
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=20060705140619.GB8452@khazad-dum.debian.net \
--to=hmh@debian.org \
--cc=hdaps-devel@lists.sourceforge.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@hansmi.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=pavel@ucw.cz \
--cc=stelian@popies.net \
/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
all inboxes | Powered by JetHome®