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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
