Generic interface for accelerometers (AMS, HDAPS, ...)

Generic interface for accelerometers (AMS, HDAPS, ...)

[Henrique de Moraes Holschuh]

We have now (or we are about to have, anyway) two drivers that export
accelerometer data: IBM's HDAPS, and Apple's AMS.  More accelerometer
drivers could be coming in the future.

Both drivers export one common set of data (accelerometer output), and some
extra information that is not related to acellerometers.  Both have at least
two functionality goals in common: to export accelerometer data to
userspace, and also to allow somehow for HD head parking when the
accelerometer detects a potentially incoming impact.

User­space utilities that interface to accelerometers like hdapsd and
smackpad could benefit from a common interface, so that they work with
HDAPS, AMS, and any other future accelerometer drivers.

If any kernel-space functionality needed by HDAPS and AMS is also shared, we
would have benefits there too.  Some examples I can think of are: generic HD
queue-freeze and HD head parking, and a generic acellerometer-driven
joystick event interface.  This would also enable generic userspace
notifiers that the HD heads have been parked, etc.

I am posting this message as a head's up for the two projects (HDAPS, AMS)
to make sure that they are actively aware of each other.  I do so in hope
that we can work in a joint, generic interface and port both drivers to this
new interface in the near future, and also that we can make as much
functionality shared between the two drivers as possible.

-- 
  "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

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Pavel Machek]

On Mon 2006-07-03 09:48:23, Henrique de Moraes Holschuh wrote:
> We have now (or we are about to have, anyway) two drivers that export
> accelerometer data: IBM's HDAPS, and Apple's AMS.  More accelerometer
> drivers could be coming in the future.
> 
> Both drivers export one common set of data (accelerometer output), and some
> extra information that is not related to acellerometers.  Both have at least
> two functionality goals in common: to export accelerometer data to
> userspace, and also to allow somehow for HD head parking when the
> accelerometer detects a potentially incoming impact.
> 
> User­space utilities that interface to accelerometers like hdapsd and
> smackpad could benefit from a common interface, so that they work with
> HDAPS, AMS, and any other future accelerometer drivers.
> 
> If any kernel-space functionality needed by HDAPS and AMS is also shared, we
> would have benefits there too.  Some examples I can think of are: generic HD
> queue-freeze and HD head parking, and a generic acellerometer-driven
> joystick event interface.  This would also enable generic userspace
> notifiers that the HD heads have been parked, etc.
> 
> I am posting this message as a head's up for the two projects (HDAPS, AMS)
> to make sure that they are actively aware of each other.  I do so in hope
> that we can work in a joint, generic interface and port both drivers to this
> new interface in the near future, and also that we can make as much
> functionality shared between the two drivers as possible.

Just use input infrastructure and be done with that? You can do
parking from userspace.

Only piece of puzzle missing is marking that input device as "this
accelerometer actually watches the whole device".
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Shem Multinymous]

On 7/4/06, Pavel Machek <pavel@ucw.cz> wrote:
> Just use input infrastructure and be done with that? You can do
> parking from userspace.

Will moving the hdapsd userspace daemon from sysfs polling to the
input infrastructure cause a noticable latency increase compared to
polling sysfs? This functionality is highly time-critical.

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.

In terms of magnitude, an hdaps readout takes ~70usec on average and
(very rarely) up to ~1msec. This is with the tp_smapi [1] patches to
hdaps, which add the checks and retries needed to ensure the readout
is valid.

BTW, can the driver tell when nothing is accessing its input device,
and avoid polling in that case?

  Shem

[1] http://thinkwiki.org/wiki/tp_smapi

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Pavel Machek]

Hi!

> >Just use input infrastructure and be done with that? You can do
> >parking from userspace.
> 
> Will moving the hdapsd userspace daemon from sysfs polling to the
> input infrastructure cause a noticable latency increase compared to
> polling sysfs? This functionality is highly time-critical.

Well, for input you should need no polling. input tells you when data
is ready.

> BTW, can the driver tell when nothing is accessing its input device,
> and avoid polling in that case?

Ask vojtech/dmitry, I guess.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Thomas Tuttle]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On July 04 at 06:26 EDT, Shem Multinymous hastily scribbled:
> Will moving the hdapsd userspace daemon from sysfs polling to the
> input infrastructure cause a noticable latency increase compared to
> polling sysfs? This functionality is highly time-critical.
>
> 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.

Just out of curiousity, is there any reason that these hard drive
parking schemes *aren't* implemented entirely in the kernel?  Wouldn't
implementing it in the kernel give it much lower latency?

-- 
Thomas Tuttle (thinkinginbinary@gmail.com)
Get Thunderbird: Reclaim your inbox. mozilla.org/products/thunderbird
aim/y!m:thinkinginbinary; icq:198113263; jabber:thinkinginbinary@jabber.org
msn: thinkinginbinary@hotmail.com; pgp: 0xAF5112C6

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Henrique de Moraes Holschuh]

On Tue, 04 Jul 2006, Pavel Machek wrote:
> Just use input infrastructure and be done with that? You can do
> parking from userspace.

The command to execute the freeze (and for how long) can certaily come from
userspace, and the logic behind that command can be an userspace
high-priority task, yes (that's how it is done in HDAPS anyway).  However,
to implement the disk head unload you need kernel code (you need to freeze
the IO queues for a while too, not just unload the heads).

Anyway, the input infrastructure is good to emulate a mouse/joystick, but we
probably want to support the following generic data channels:

1. Absolute acceleration output stream (either in hardware units, or
   normalized to G or mG if at all possible) for X, Y, Z.  Does the input
   infrastructure work well for reporting absolute numbers in a reasonably
   constant rate?
   
   This is what HD head unload policy daemons want to know, and the stream
   usually needs to offer datapoints somewhere between 20Hz and 100Hz
   without excessive jitter to be useful for more advanced filtering (like
   masking-off periodic movement such as the one caused by train tracks).

2. As easy-to-use as possible joystick and mouse emulation (for toys and 
   gaming), which probably means auto-calibrating ones when possible
   and thus making them unsuitable channels for (1) above.

3. Control of accelerometer parameters:
   3a. Report of accelerometer type (hdaps, ams, etc) and other metadata
       (name, location, what it is measuring (system accel, hd-bay 
       accel...))
   3b. Accelerometer polling frequency
   3c. Enable/disable joystick and mouse emulation control
   etc.

And, of course, userspace must be able to easily find the accelerometer
outputs and diferentiate them from other joystick/mouse interfaces.  This is
a task for udev, I suppose.

It is also very helpful to be able to know when something is using any of
the accelerometer output channels, so as to shut it down (or stop talking to
it) when it is uneeded.  I don't know about AMS, but talking to HDAPS when
you don't need to does waste enough system resources and power to actually
justify implementing this.

If we cannot detect automatically when userspace is paying attention to the
accelerometer through the input layer, then that means we will need the
enable/disable functionality already provided by the device model through
sysfs.

> Only piece of puzzle missing is marking that input device as "this
> accelerometer actually watches the whole device".

Well, it is very important to be able to easily find all data and channels
pertaining for a given accelerometer, and the accelerometer metadata should
indeed give userspace an idea of WHAT it is measuring the acceleration of
:-)

-- 
  "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

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Pavel Machek]

Hi!

> > Just use input infrastructure and be done with that? You can do
> > parking from userspace.
> 
> The command to execute the freeze (and for how long) can certaily come from
> userspace, and the logic behind that command can be an userspace
> high-priority task, yes (that's how it is done in HDAPS anyway).  However,
> to implement the disk head unload you need kernel code (you need to freeze
> the IO queues for a while too, not just unload the heads).

Okay, yes, this part is needed. It is useful for more than
accelerometers...


> Anyway, the input infrastructure is good to emulate a mouse/joystick, but we
> probably want to support the following generic data channels:
> 
> 1. Absolute acceleration output stream (either in hardware units, or
>    normalized to G or mG if at all possible) for X, Y, Z.  Does the input
>    infrastructure work well for reporting absolute numbers in a reasonably
>    constant rate?
>    
>    This is what HD head unload policy daemons want to know, and the stream
>    usually needs to offer datapoints somewhere between 20Hz and 100Hz
>    without excessive jitter to be useful for more advanced filtering (like
>    masking-off periodic movement such as the one caused by train tracks).
> 
> 2. As easy-to-use as possible joystick and mouse emulation (for toys and 
>    gaming), which probably means auto-calibrating ones when possible
>    and thus making them unsuitable channels for (1) above.

Well, I'd just provide 1. Providing 2 seems like task for some
userspace filtering library.

> 3. Control of accelerometer parameters:
>    3a. Report of accelerometer type (hdaps, ams, etc) and other metadata
>        (name, location, what it is measuring (system accel, hd-bay 
>        accel...))

Well, if your system is accelerating at different speed than hd-bay,
then your machine is either _way_ too big, or you are in bad trouble.

Ask Dmitry or vojtech, I believe input can provide such metadata. (I
left most of the quoted text so that vojtech can reply easily).

								Pavel

>    3b. Accelerometer polling frequency
>    3c. Enable/disable joystick and mouse emulation control
>    etc.
> 
> And, of course, userspace must be able to easily find the accelerometer
> outputs and diferentiate them from other joystick/mouse interfaces.  This is
> a task for udev, I suppose.
> 
> It is also very helpful to be able to know when something is using any of
> the accelerometer output channels, so as to shut it down (or stop talking to
> it) when it is uneeded.  I don't know about AMS, but talking to HDAPS when
> you don't need to does waste enough system resources and power to actually
> justify implementing this.
> 
> If we cannot detect automatically when userspace is paying attention to the
> accelerometer through the input layer, then that means we will need the
> enable/disable functionality already provided by the device model through
> sysfs.
> 
> > Only piece of puzzle missing is marking that input device as "this
> > accelerometer actually watches the whole device".
> 
> Well, it is very important to be able to easily find all data and channels
> pertaining for a given accelerometer, and the accelerometer metadata should
> indeed give userspace an idea of WHAT it is measuring the acceleration of
> :-)
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Dmitry Torokhov]

On Tuesday 04 July 2006 06:26, Shem Multinymous wrote:
> 
> BTW, can the driver tell when nothing is accessing its input device,
> and avoid polling in that case?
> 

Yes (->open is called when there is a client opening one of the input
interfaces), but I don't think that "oh shit I dropped my laptop" events
belong to input layer.

-- 
Dmitry

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Vojtech Pavlik]

On Wed, Jul 05, 2006 at 01:57:17AM +0200, Pavel Machek wrote:

> > Anyway, the input infrastructure is good to emulate a mouse/joystick, but we
> > probably want to support the following generic data channels:
> > 
> > 1. Absolute acceleration output stream (either in hardware units, or
> >    normalized to G or mG if at all possible) for X, Y, Z.  Does the input
> >    infrastructure work well for reporting absolute numbers in a reasonably
> >    constant rate?
> >    
> >    This is what HD head unload policy daemons want to know, and the stream
> >    usually needs to offer datapoints somewhere between 20Hz and 100Hz
> >    without excessive jitter to be useful for more advanced filtering (like
> >    masking-off periodic movement such as the one caused by train tracks).

Yes, this is what the input subsystem normally works with - 32-bit
absolute (and relative) numbers at rates around 100 Hz. It's how the
data from joysticks (and mice) look like.

> > 2. As easy-to-use as possible joystick and mouse emulation (for toys and 
> >    gaming), which probably means auto-calibrating ones when possible
> >    and thus making them unsuitable channels for (1) above.
> 
> Well, I'd just provide 1. Providing 2 seems like task for some
> userspace filtering library.

Assuming you use the ABS_X, ABS_Y, and ABS_Z for the acceleration (which
is not necessarily ideal), you'll get a joystick emulation automagically
through the input subsystem without any additional coding.

> > 3. Control of accelerometer parameters:
> >    3a. Report of accelerometer type (hdaps, ams, etc) and other metadata
> >        (name, location, what it is measuring (system accel, hd-bay 
> >        accel...))
> 
> Well, if your system is accelerating at different speed than hd-bay,
> then your machine is either _way_ too big, or you are in bad trouble.
> 
> Ask Dmitry or vojtech, I believe input can provide such metadata. (I
> left most of the quoted text so that vojtech can reply easily).

It currently doesn't. It reports the device ID as a couple of 16-bit
integers, and how the input subsystem sees it. There is currently no way
to get at device-specific data, although this could be reasonably easily
done through sysfs I believe.

> >    3b. Accelerometer polling frequency

Module parameter, changeable via sysfs?

> >    3c. Enable/disable joystick and mouse emulation control
> >    etc.
> > 
> > And, of course, userspace must be able to easily find the accelerometer
> > outputs and diferentiate them from other joystick/mouse interfaces.  This is
> > a task for udev, I suppose.

Yup.

> > It is also very helpful to be able to know when something is using any of
> > the accelerometer output channels, so as to shut it down (or stop talking to
> > it) when it is uneeded. 

This is done automatically by the input subsystem. When the last user
close()s any of the related devices, the driver gets notified that it
can stop the hardware.

> > I don't know about AMS, but talking to HDAPS when
> > you don't need to does waste enough system resources and power to actually
> > justify implementing this.

I'd doubt any of the accelerometer implementations would consume much
power or CPU.

> > If we cannot detect automatically when userspace is paying attention to the
> > accelerometer through the input layer, then that means we will need the
> > enable/disable functionality already provided by the device model through
> > sysfs.
> > 
> > > Only piece of puzzle missing is marking that input device as "this
> > > accelerometer actually watches the whole device".
> > 
> > Well, it is very important to be able to easily find all data and channels
> > pertaining for a given accelerometer, and the accelerometer metadata should
> > indeed give userspace an idea of WHAT it is measuring the acceleration of

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [lm-sensors] Generic interface for accelerometers (AMS, HDAPS, ...)

[Jean Delvare]

(Does this conversation really need to happen on 3 different mailing
lists at once?)

> > 3. Control of accelerometer parameters:
> >    3a. Report of accelerometer type (hdaps, ams, etc) and other metadata
> >        (name, location, what it is measuring (system accel, hd-bay 
> >        accel...))
> 
> Well, if your system is accelerating at different speed than hd-bay,
> then your machine is either _way_ too big, or you are in bad trouble.

Not necessarily. If the system is spinning, each point has its own
acceleration vector. Having two accelerometers in a system would be a
convenient way to detect that kind of movement, and I wouldn't be
surprised to see it happen.

-- 
Jean Delvare

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

[I hope I managed to not break the thread]

> 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...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Henrique de Moraes Holschuh]

On Wed, 05 Jul 2006, Vojtech Pavlik wrote:
> > > I don't know about AMS, but talking to HDAPS when
> > > you don't need to does waste enough system resources and power to actually
> > > justify implementing this.
> 
> I'd doubt any of the accelerometer implementations would consume much
> power or CPU.

It is not just CPU or power, although IMO striving for perfection on power
management in a laptop is almost always a good thing if it can be done
safely.

HDAPS talks to the embedded controller using IO over the LPC bus, and not to
the accelerometer chip or to a simple A/D i2c chip which is used excusively
for accelerometer access.  The EC interface for HDAPS data retrieval is
not friendly to any errors, and hardlocks the machine somehow if any
firmware bugs hit or if we violate any of the rules (that are not written
anywhere) about how to access the EC without geting the SMBIOS unhappy.

So, turning off HDAPS polling while it is not necessary really looks like a
good idea overall.

We are investigating the ACPI global lock as a way to at least get the
SMBIOS to stay away from the EC while we talk to it, but we don't know if
the entire SMBIOS firmware respects that lock.

-- 
  "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

Re: [Hdaps-devel] Generic interface for accelerometers (AMS, HDAPS, ...)

[Henrique de Moraes Holschuh]

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

Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Pavel Machek]

Hi!

> > > > I don't know about AMS, but talking to HDAPS when
> > > > you don't need to does waste enough system resources and power to actually
> > > > justify implementing this.
> > 
> > I'd doubt any of the accelerometer implementations would consume much
> > power or CPU.

Actually polling at 100Hz probably _is_ going to be measurable on
modern CPUs -- because it means that CPU has to exit C4. It will not
be too bad, hopefully.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html