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: 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: 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: 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: Generic interface for accelerometers (AMS, HDAPS, ...)

[Robert Hancock]

Henrique de Moraes Holschuh wrote:
> 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.

It had better, that is exactly what the ACPI Global Lock is supposed to 
prevent (concurrent access to non-sharable resources between the OS and 
SMI code). The ACPI DSDT contains information on whether or not the 
machine requires the Global Lock in order to access the EC or whether it 
is safe to access without locking.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

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

[Vojtech Pavlik]

On Wed, Jul 05, 2006 at 05:59:29PM -0600, Robert Hancock wrote:
> Henrique de Moraes Holschuh wrote:
> >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.
> 
> It had better, that is exactly what the ACPI Global Lock is supposed to 
> prevent (concurrent access to non-sharable resources between the OS and 
> SMI code). The ACPI DSDT contains information on whether or not the 
> machine requires the Global Lock in order to access the EC or whether it 
> is safe to access without locking.
 
Isn't that vaild only if you actully use ACPI to access the EC? (AFAIK
the HDAPS driver does direct port access.)

-- 
Vojtech Pavlik
Director SuSE Labs

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

[Robert Hancock]

Vojtech Pavlik wrote:
>>> 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.
>> It had better, that is exactly what the ACPI Global Lock is supposed to 
>> prevent (concurrent access to non-sharable resources between the OS and 
>> SMI code). The ACPI DSDT contains information on whether or not the 
>> machine requires the Global Lock in order to access the EC or whether it 
>> is safe to access without locking.
>  
> Isn't that vaild only if you actully use ACPI to access the EC? (AFAIK
> the HDAPS driver does direct port access.)

Likely - and I think you would have to do that anyway, otherwise how are 
you going to prevent the ACPI code from concurrently accessing the EC at 
the same time as the HDAPS driver? In any case, only ACPI knows how to 
safely access the EC (Global Lock needed, or not) so it should be the 
one doing the accesses.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[Henrique de Moraes Holschuh]

On Thu, 06 Jul 2006, Vojtech Pavlik wrote:
> > >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.
> > 
> > It had better, that is exactly what the ACPI Global Lock is supposed to 
> > prevent (concurrent access to non-sharable resources between the OS and 
> > SMI code). The ACPI DSDT contains information on whether or not the 
> > machine requires the Global Lock in order to access the EC or whether it 
> > is safe to access without locking.
>  
> Isn't that vaild only if you actully use ACPI to access the EC? (AFAIK
> the HDAPS driver does direct port access.)

It better be valid for any OS-side access to the EC, otherwise the ACPI
global lock would be utterly useless.  The system vendor would have done its
own "global-lock-like" functionality without the need for an ACPI global
lock specification.

What is not clear to me is whether an ACPI DSDT method is on the "OS side"
or on the "SMM side" of the ACPI global 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: Generic interface for accelerometers (AMS, HDAPS, ...)

[Robert Hancock]

Henrique de Moraes Holschuh wrote:
> On Thu, 06 Jul 2006, Vojtech Pavlik wrote:
>>>> 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.
>>> It had better, that is exactly what the ACPI Global Lock is supposed to 
>>> prevent (concurrent access to non-sharable resources between the OS and 
>>> SMI code). The ACPI DSDT contains information on whether or not the 
>>> machine requires the Global Lock in order to access the EC or whether it 
>>> is safe to access without locking.
>>  
>> Isn't that vaild only if you actully use ACPI to access the EC? (AFAIK
>> the HDAPS driver does direct port access.)
> 
> It better be valid for any OS-side access to the EC, otherwise the ACPI
> global lock would be utterly useless.  The system vendor would have done its
> own "global-lock-like" functionality without the need for an ACPI global
> lock specification.
> 
> What is not clear to me is whether an ACPI DSDT method is on the "OS side"
> or on the "SMM side" of the ACPI global lock.

That would be on the OS side of the global lock.. However the OS still 
needs to maintain its own synchronization between its accesses to the 
controller, the global lock is not intended for that purpose. It doesn't 
sound like the HDAPS driver and the ACPI code are necessarily 
synchronizing their accesses (though I can't say I've looked at the code).

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[Vojtech Pavlik]

On Thu, Jul 06, 2006 at 11:46:04PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Jul 2006, Vojtech Pavlik wrote:
> > > >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.
> > > 
> > > It had better, that is exactly what the ACPI Global Lock is supposed to 
> > > prevent (concurrent access to non-sharable resources between the OS and 
> > > SMI code). The ACPI DSDT contains information on whether or not the 
> > > machine requires the Global Lock in order to access the EC or whether it 
> > > is safe to access without locking.
> >  
> > Isn't that vaild only if you actully use ACPI to access the EC? (AFAIK
> > the HDAPS driver does direct port access.)
> 
> It better be valid for any OS-side access to the EC, otherwise the ACPI
> global lock would be utterly useless.  The system vendor would have done its
> own "global-lock-like" functionality without the need for an ACPI global
> lock specification.

That's what I fear does happen on many systems.

> What is not clear to me is whether an ACPI DSDT method is on the "OS side"
> or on the "SMM side" of the ACPI global lock.

No idea, sorry.

-- 
Vojtech Pavlik
Director SuSE Labs