[lm-sensors] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)
ben-linux at fluff.org
Thu Jul 24 12:08:33 CEST 2008
On Thu, Jul 24, 2008 at 11:44:36AM +0200, Eric Piel wrote:
> Henrique de Moraes Holschuh schreef:
>> On Wed, 23 Jul 2008, Jonathan Cameron wrote:
>>> The subsystem is now in a functional state with a small set of drivers:
>>> Max1363 (supports numerous Maxim i2c ADC's) (tested with max1363 and max1238 chips)
>>> - Uses a periodic timer to provide ring buffer mode.
>>> - All reads form these devices are scan modes so direct single element access
>>> is not provided.
>>> - Monitor mode on max1363 is not yet supported (need to do a bit debugging of
>>> the board I have so as to be able to test this).
>>> ST LIS3L02DQ - SPI accelerometer.
>>> - Uses a datardy interrupt to driver a software ring buffer.
>>> - Most functionality of this device is supported.
>>> VTI SCA3000 (tested with an e05)
>>> - Hardware ring buffer.
>> I'd like to see something done to have the common parts of interfaces of the
>> same class (e.g. accelerometers) be standard. Like hwmon does with
>> temp#_input, etc.
>> Otherwise you made it easier to write drivers, but did nothing to help
>> userspace to USE the drivers :-)
> I completely agree with Henrique. There already exist 3 accelerometer
> drivers in the kernel (and I'm writing a fourth on). What we are
> desperately in need of is a _user_ interface. So that a generic program
> can pop up and say "Oh, there is an accelerometer on this computer, I'll
> use it to detect free falls."
> IMHO, I think the ADC should have a much more specific and specialised
> (user and kernel) API corresponding to the accelerometers. Granted, you
> probably had in mind only the accelerometers for industrial usage, but
> it would be much better if the current accelerometer drivers had a
> reason to be ported to this new subsystem.
> In particular, what I think would be worthy would be:
> * Up to 3 pre-defined axes (X, Y, Z) - that's provided by your current
> version of industrialio
> * If the accelerometer is soldered on the computer, define once for all
> to which _physical_ movement corresponds which axis (eg: a laptop on its
> normal position going up has axis Z increasing).
> * Free fall event. Either it's hardware detected, or the accelerometer
> infrastructure will detect it in software.
> * For each axis, what is the maximum and minimum bound and the unit -
> Probably worthy for the whole ADC infrastructure
> * Joystick emulation (calibrated so that when the computer is not
> moving, all the values are at 0). All the current drivers have it.
I think if we're trying to make something that will cover a number
of device classes, we need to be more like HID and have a system
that reports and possibly records the following:
1) What data is possible to be returned from each event, with the
units, magnitude and any scale applied by the device sending.
2) Each event should be able to report a number of items, so that
if the sensor reports X/Y/Z in one go, there is just a single
event containing those values.
3) A well defined set of information that can be read (like #1)
that can provide details of the device and how it relates to
the environment it is in.
Ben (ben at fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
More information about the lm-sensors