Accelerometer, Gyros and ADC's etc within the kernel.

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

Any other suggestions welcome!

This email is basically a request for opinions on how and where such sensors
should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

Any other suggestions welcome!

To illustrate the sort of devices here are a few I have drivers written for or will
shortly be writing (some submitted to hwmon and spi mailing lists, some not
finished as of yet)

ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt pin
raised high on new data being available. Currently the driver assumes, if interrupts are enabled, that this is connected to a specified gpio.
(http://www.st.com/stonline/books/pdf/docs/10175.pdf)

VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI device. Can operate either in buffered or direct mode. In buffered mode, interrupts
can be used to indicate when the ring buffer is 3/4 full triggering a download to
a larger ring buffer in the kernel if necessary.
(http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/)

Analog Devices ADIS16350 combined 3D accelerometer and gyro unit. SPI device.
(http://www.analog.com/en/prod/0,,764_801_ADIS16350%2C00.html)

Maxim MAX1363, MAX1238 ADC's. I2C devices. Some SPI ADC's (www.analog.com for
examples)

Would be nice if practical to allow the framework to include RS232 devices such
as those from www.xsens.com, www.isense.com and others.

Hi Jonathan,

Quoted 16 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

Quoted 4 lines

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

Quoted 3 lines

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these devices have much in common with the traditional hardware monitoring components anyway.

I'm not sure what "straight ADC driver" you are referring to, but anything which measures a voltage and exports the reading to user-space is, well, a voltage sensor, and thus fix within hwmon. If the same chip is used for a higher-level, dedicated function then we would probably have a separate driver for it, outside of hwmon.

Quoted 2 lines

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Would be OK.

Or:

* Place these within the input subsystem. You might want to discuss this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The Wii remote is essentially a joystick, and joysticks belong to the input subsystem.

This all sounds quite different from our hwmon drivers. Our hwmon drivers read all the sensor values at once and cache the readings for a couple seconds, so you can't get an instant reading at any time, and they also don't support interrupts in general.

Quoted 5 lines

ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt pin
raised high on new data being available. Currently the driver assumes, if interrupts are enabled, that this is connected to a specified gpio.
(http://www.st.com/stonline/books/pdf/docs/10175.pdf)

FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port.

WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux. You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using.

If you have SPI hardware then
you need to know where to pull the data from. The problem doesn't seem to generalize well.

Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting.

Another problem area is around SPI itself. There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Quoted 8 lines

VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI device. Can operate either in buffered or direct mode. In buffered mode, interrupts
can be used to indicate when the ring buffer is 3/4 full triggering a download to
a larger ring buffer in the kernel if necessary.
(http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/)

ring buffered data can make RT applications harder...

Quoted 4 lines

Would be nice if practical to allow the framework to include RS232 devices such
as those from www.xsens.com, www.isense.com and others.

I'm not sure what you are asking for, you started off with SPI driver for interfacing a handful of accelerometer devices. Now your talking about the serial port.

Besides the consumer of accelerometer data is user space applications (mine attempt to be somewhat RT applications)

Quoted 22 lines

Hi Jonathan,

Quoted 17 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to fit with in an particular subsystem of the kernel. A previous discussion on lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

Quoted 7 lines

Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

100% ACK. And the functionality here is something like "industrial control" or "automation I/O".

If this sort of hardware appears as device
with mappable memory, we can handle it with UIO, but for SPI, I2C, USB, serial, we should have a new subsystem. It should handle not only input, but also similar output devices. It doesn't make sense to have ADCs in one subsystem, and DACs in a different one.

Quoted 8 lines

Quoted 3 lines

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these devices have much in common with the traditional hardware monitoring components anyway.

Agreed, hwmon devices are not really tuned for maximum performance, for example. Performance is often critical in automation control applications.

Quoted 7 lines

I'm not sure what "straight ADC driver" you are referring to, but anything which measures a voltage and exports the reading to user-space is, well, a voltage sensor, and thus fix within hwmon. If the same chip is used for a higher-level, dedicated function then we would probably have a separate driver for it, outside of hwmon.

Quoted 5 lines

Quoted 3 lines

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Would be OK.

Definitely.

Quoted 2 lines

Or:

Quoted 5 lines

* Place these within the input subsystem. You might want to discuss this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The Wii remote is essentially a joystick, and joysticks belong to the input subsystem.

This might apply to some devices, but not all. And the requirements are quite different, I think.

Quoted 5 lines

This all sounds quite different from our hwmon drivers. Our hwmon drivers read all the sensor values at once and cache the readings for a couple seconds, so you can't get an instant reading at any time, and they also don't support interrupts in general.

Exactly.

Definitely agreed that it makes sense to put DACs and ADCs in the same general place and obviously there are plenty of devices out there that do both.

Hi Jonathan,

Quoted 16 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

Quoted 4 lines

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

Quoted 2 lines

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these devices have much in common with the traditional hardware monitoring components anyway.

I'm not sure what "straight ADC driver" you are referring to, but anything which measures a voltage and exports the reading to user-space is, well, a voltage sensor, and thus fix within hwmon. If the same chip is used for a higher-level, dedicated function then we would probably have a separate driver for it, outside of hwmon.

Quoted 2 lines

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Would be OK. Or:

* Place these within the input subsystem. You might want to discuss this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The Wii remote is essentially a joystick, and joysticks belong to the input subsystem.

I don't think that input subsystem woudl be the best choice. While we do support the event-driven mechanism for delivering information to userspace input is mostly oriented for human interface devices, not general data acquisition. If anything input_dev is too fat. Another thing is that input layer anonymizes input devices, makes them capability-oriented. I.e. we dont really care what model of joystick we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and userpsace can use it whether it a simple analog joystick or something fancy and USB connected. For your purposes you probably do want to know what the device is and what exactly being sampled/measured.

I'd go with a lean and mean new subsytem.

This all sounds quite different from our hwmon drivers. Our hwmon drivers read all the sensor values at once and cache the readings for a couple seconds, so you can't get an instant reading at any time, and they also don't support interrupts in general.

Quoted 1 line

ST Micro LIS3L02DQ 3D accelerometer.  ...

FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port.

WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux.  You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using.  If you have SPI hardware then you need to know where to pull the data from.  The problem doesn't seem to generalize well.

Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting.

Another problem area is around SPI itself.  There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Quoted 4 lines

This all sounds quite different from our hwmon drivers. Our hwmon drivers read all the sensor values at once and cache the readings for a couple seconds, so you can't get an instant reading at any time, and they also don't support interrupts in general.

That's something of an issue when the hardware monitor triggers alarms though, right? I couldn't figure out how to get a TMP75 alert out to any userspace code that would care, to pick one example, even after teaching the i2c core how to handle SMBus alerts. ;)

I suppose this just emphasizes the point made by Hans that we kind of need (industrial) "control" components (or "data acquisition"?) not just "monitoring" ones.

Such alarms are of course different from the "data ready" signals of an accelerometer.

Hi Mark,

Quoted 7 lines

Quoted 5 lines

ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt pin
raised high on new data being available. Currently the driver assumes, if interrupts are enabled, that this is connected to a specified gpio.
(http://www.st.com/stonline/books/pdf/docs/10175.pdf)

FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port.

That's certainly interesting and I guess one of the easiest ways of getting data from spi to a desktop machine. I'll admit my interest is more with embedded machines.

Quoted 5 lines

WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux. You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using.

Yes, and that means we would use the delights of platform data and the generic gpio subsystem. Although I believe generic gpio isn't available on every platform as yet, it is getting there and is certainly in place for ARM (and cleans up an awful lot of hardware interfaces!)

Quoted 3 lines

If you have SPI hardware then
you need to know where to pull the data from. The problem doesn't seem to generalize well.

Yes, the intention would not be to generalize the hardware comms, but rather the
interface on the user side. This is similar to a number of other subsystems such as hwmon, where you share functionality as much as possible, but allow very different approaches to things like actual hardware register reads as and when they are necessary.

Quoted 4 lines

Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting.

Definitely. Obviously the accuracy of this time stamp is going to be limited by
the variable nature of when an interrupt handler picks it up, but knowledge of the device specs can allow filtering of this timing data. This is certainly something we would want to consider at a later date although it may well be more sensible to leave this to userspace applications.

Quoted 3 lines

Another problem area is around SPI itself. There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Indeed. This is well handled by the SPI subsystem. I've spent far too much time with a scope recently fiddling with these parameters for badly documented chips!

Quoted 10 lines

Quoted 9 lines

VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI
device. Can operate either in buffered or direct mode. In buffered mode, interrupts
can be used to indicate when the ring buffer is 3/4 full triggering a download to
a larger ring buffer in the kernel if necessary.
(http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/)

ring buffered data can make RT applications harder...

Agreed. With this sort of device two modes would be needed (and are supported by the hardware). The first gives direct data access and the second uses the ring buffer. Which you use would obviously be dependent on the application. Some applications want the most recent data on all occasions, whilst some will be more interested in ensuring that all data is captured.

Quoted 7 lines

Quoted 4 lines

Would be nice if practical to allow the framework to include RS232 devices such
as those from www.xsens.com, www.isense.com and others.

I'm not sure what you are asking for, you started off with SPI driver for interfacing a handful of accelerometer devices. Now your talking about the serial port.

The question here is concerned with standardising mainly the userspace interfaces (and hardware interfaces only when appropriate). Some of these devices (the ST accel above for example) support multiple hardware interfaces specs (I2C and SPI for that one). So in a similar way to it making sense to group all TV adapters irrespective of how they are interfaced to the computer, in order to ensure a consistent interface to user space, it makes sense to share these interfaces amongst drivers talking to these devices irrespective of what their hardware interface is.

Quoted 2 lines

Besides the consumer of accelerometer data is user space applications (mine attempt to be somewhat RT applications)

Thanks,

--
Jonathan Cameron

Quoted 4 lines · mark gross

Quoted 1 line

ST Micro LIS3L02DQ 3D accelerometer.  ...

FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port.

Jonathan neglected to mention that he's already sent a driver for this to the SPI list. ;)

Which is part of the reason for asking this question. Right now that driver sits in drivers/spi/lis3l02dq.c but that is probably not its best long-term domicile.

Quoted 7 lines

WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux.  You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using.  If you have SPI hardware then you need to know where to pull the data from.  The problem doesn't seem to generalize well.

I guess I don't follow. The SPI framework handles all that stuff already, even if you're bitbanging. Though to be sure, if you're bitbanging SPI you want your platform to be able to inline those GPIO calls so those inner loops only take a few instructions per bit ... also solved! :)

Quoted 4 lines

Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting.

True. I imagine a few other such issues will appear once more folk than Jonathan are using these sorts of sensors on Linux. I'd expect the sample stream to have internal timestamps for truly critical systems, unless variability in when the host makes timestamps is not really an issue.

Quoted 4 lines

Another problem area is around SPI itself.  There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Midpoint? That's not one I've come across before. All four standard SPI clock/sample/shift modes are already supported in the SPI framework though. Ditto active-high chipselects (vs normal active-low) etc.

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

Hi Jonathan,

Quoted 36 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

Also, I'd mention that most ADC devices could report in "bunched" mode, i.e.

1. Request ADC readings from pins X, Y, Z1, Z2.
2. Wait for single IRQ
3. Read all the results

At handhelds.org, we've wrote quite good (I think) ADC subsystem, that keeps in mind ADC capabilities. It implements two interfaces:
in-kernel (e.g. for touchscreen drivers), and userspace interface via sysfs. I was planning to implement drivers/input/ interface too.

Quoted 39 lines · Anton Vorontsov

Hi Jonathan,

Quoted 36 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

The two drivers i've seen so far use the input subsystem to report their data to the user. I'm working on an driver for the SMB380 which can be both i2c and spi.

Quoted 7 lines

Also, I'd mention that most ADC devices could report in "bunched" mode, i.e.

1. Request ADC readings from pins X, Y, Z1, Z2.
2. Wait for single IRQ
3. Read all the results

Quoted 4 lines

At handhelds.org, we've wrote quite good (I think) ADC subsystem, that keeps in mind ADC capabilities. It implements two interfaces:
in-kernel (e.g. for touchscreen drivers), and userspace interface via sysfs. I was planning to implement drivers/input/ interface too.

handhelds.org's track history of getting things into the kernel is poor.

Quoted 24 lines · Jean Delvare

Hi Jonathan,

Quoted 20 lines · Jonathan Cameron

This email is basically a request for opinions on how and where such sensors should be integrated into the kernel.

To set the scene...

Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to
fit with in an particular subsystem of the kernel. A previous discussion on
lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions
of such non hardware monitoring sensors.

The obvious possibilities are:

* To place the various drivers within the spi / i2c etc subsystems as relevant.

Quoted 6 lines

Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

Quoted 17 lines

Quoted 2 lines

* To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon)

Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these devices have much in common with the traditional hardware monitoring components anyway.

I'm not sure what "straight ADC driver" you are referring to, but anything which measures a voltage and exports the reading to user-space is, well, a voltage sensor, and thus fix within hwmon. If the same chip is used for a higher-level, dedicated function then we would probably have a separate driver for it, outside of hwmon.

Quoted 2 lines

* To create a new subsystem, or perhaps merely sysfs class to contain these elements.

Quoted 7 lines

Would be OK. Or:

* Place these within the input subsystem. You might want to discuss this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The Wii remote is essentially a joystick, and joysticks belong to the input subsystem.

I don't think that input subsystem woudl be the best choice. While we do support the event-driven mechanism for delivering information to userspace input is mostly oriented for human interface devices, not general data acquisition. If anything input_dev is too fat. Another thing is that input layer anonymizes input devices, makes them capability-oriented. I.e. we dont really care what model of joystick we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and userpsace can use it whether it a simple analog joystick or something fancy and USB connected. For your purposes you probably do want to know what the device is and what exactly being sampled/measured.

Quoted 10 lines

Typical requirements within an application include simply polling for current
readings, and using device triggered interrupts to grab data continuously to a
ring buffer, for collection by suitable userspace code. Obviously it would be
desirable to standardize sysfs controls for various calibration parameters as
much as possible across the various devices.

Also, I'd mention that most ADC devices could report in "bunched" mode, i.e.

1. Request ADC readings from pins X, Y, Z1, Z2.
2. Wait for single IRQ
3. Read all the results

At handhelds.org, we've wrote quite good (I think) ADC subsystem, that keeps in mind ADC capabilities. It implements two interfaces:
in-kernel (e.g. for touchscreen drivers), and userspace interface via sysfs. I was planning to implement drivers/input/ interface too. I always don't find time to clean it up and submit, though.

Here is ADC subsystem itself:
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/adc.c
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/include/linux/adc.h
^ It is in drivers/misc/, but I think better placement would be
drivers/adc.

Some drivers for this subsystem:
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/ads7846_adc_ssp.c
^ ADC driver for ADS7846 chips (HP iPaq hx4700 and some HTC phones, the
driver is using SSP subsystem, switching it to the SPI is still in my enless TODO list).

http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/samcop_adc.c
^ SAMCOP (HP iPaq H5xxx) ADC driver.

http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/tsc2200_adc_ssp.c
^ TSC2200 ADC driver (used AFAIK in some HTC phones, or ASUS handhelds).

http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/ad7877.c
^ AD7877 ADC driver (HTC phones too, IIRC).

Now, The Generic ADC Touchscreen Driver (tested to work quite good with all above ADC drivers on appropriate hardware):
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/input/touchscreen/ts-adc.c

And finally, ADC Battery driver ("backup" batteries in the iPaq devices usually report their voltage via ADC chip, the same used by the touchscreen).
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/power/adc_battery.c

p.s.
I have more recent (for current Linus' tree) code for ADC subsystem, but it still needs some love to be submittable.

The two drivers i've seen so far use the input subsystem to report their data to the user. I'm working on an driver for the SMB380 which can be both i2c and spi.

Quoted 5 lines

The two drivers i've seen so far use the input subsystem to report their data to the user. I'm working on an driver for the SMB380 which can be both i2c and spi.

Yes, the ST accel I'm using (LIS3L02DQ) is like that as well, so we definitely need
to implement the ability to do this cleanly!

Quoted 11 lines

I don't think that input subsystem woudl be the best choice. While we do support the event-driven mechanism for delivering information to userspace input is mostly oriented for human interface devices, not general data acquisition. If anything input_dev is too fat. Another thing is that input layer anonymizes input devices, makes them capability-oriented. I.e. we dont really care what model of joystick we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and userpsace can use it whether it a simple analog joystick or something fancy and USB connected. For your purposes you probably do want to know what the device is and what exactly being sampled/measured.

Can you explain to me how the input system anonymizes things? I thought it was quite easy to read the name of the device? You could easily add a symlink from the driver's device binding in sysfs to the relevant input device as well.

Also, why would you not want all your accelerometers grouped into a set of accelerometers? If your application software just searches all input devices for anything reporting itself as an accelerometer, then it would get the right result...

Quoted 5 lines

Quoted 4 lines

Another problem area is around SPI itself.  There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Quoted 4 lines

Midpoint?  That's not one I've come across before.  All four standard SPI clock/sample/shift modes are already supported in the SPI framework though.  Ditto active-high chipselects (vs normal active-low) etc.

Yeah, its one of the sampling modes for the PIC18F4455 its one of the master mode sampling options  (see page 194 of
http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf )

Ok, say the HW SPI is pushed down to some lower level driver. These things send streaming data, and sometimes signals (free-fall detect) out of band WRT the SPI comms.

I would like to see how a higher level API could encapsulate the generalization of a class of such devices.

Also, I'm not sure how one could generalize SPI communications at a high level given its bi-directional nature.

I guess I need to see some header files showing what you are thinking about.

Keep in mind that one abstraction of these devices is they are simply streaming A2D 16 bit data values over SPI (or I2C). The size of the data set is a function of the sensor axes.

Quoted 41 lines

Quoted 4 lines

Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting.

Definitely. Obviously the accuracy of this time stamp is going to be limited by
the variable nature of when an interrupt handler picks it up, but knowledge of the device specs can allow filtering of this timing data. This is certainly something we would want to consider at a later date although it may well be more sensible to leave this to userspace applications.

Quoted 3 lines

Another problem area is around SPI itself. There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next.

Indeed. This is well handled by the SPI subsystem. I've spent far too much time with a scope recently fiddling with these parameters for badly documented chips!

Quoted 10 lines

Quoted 9 lines

VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI
device. Can operate either in buffered or direct mode. In buffered mode, interrupts
can be used to indicate when the ring buffer is 3/4 full triggering a download to
a larger ring buffer in the kernel if necessary.
(http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/)

ring buffered data can make RT applications harder...

Agreed. With this sort of device two modes would be needed (and are supported by the hardware). The first gives direct data access and the second uses the ring buffer. Which you use would obviously be dependent on the application. Some applications want the most recent data on all occasions, whilst some will be more interested in ensuring that all data is captured.

Quoted 6 lines

Quoted 3 lines

Would be nice if practical to allow the framework to include RS232 devices such
as those from www.xsens.com, www.isense.com and others.

I'm not sure what you are asking for, you started off with SPI driver for interfacing a handful of accelerometer devices. Now your talking about the serial port.

Quoted 8 lines

The question here is concerned with standardising mainly the userspace interfaces (and hardware interfaces only when appropriate). Some of these devices (the ST accel above for example) support multiple hardware interfaces specs (I2C and SPI for that one). So in a similar way to it making sense to group all TV adapters irrespective of how they are interfaced to the computer, in order to ensure a consistent interface to user space, it makes sense to share these interfaces amongst drivers talking to these devices irrespective of what their hardware interface is.

I guess I need to see some header files to see where you are going with this idea. To be useful you'll also need to handle rotation sensors and communicate the temperature bias's up the stack too.

good luck keep me posted on where your going with this, it is interesting to me.

Dear All,

This email is mainly to give people an idea of current progress towards a new
subsystem as discussed in the thread starting with
http://lkml.org/lkml/2008/5/20/135

Sorry for the mass list bombardment, but clearly some elements of this discussion
will end up in various different territories.

Some elements of a prototype subsystem are in place. It draws very heavily on parts of the input and hwmon subsystems diverging only where necessary.

The only test driver currently integrated is for an ST LIS3L02DQ accelerometer
which has more than a few quirks to make it tricky to handle (and some what sketchy documentation.) More chips will follow over next week or so but hopefully the driver for this chip gives enough of an idea of how I envision the system working to encourage discussion / advice.

Note that I haven't dealt with anywhere near all the possible locking issues etc and am well aware that this needs to be done. Other cleanups that will need to be done include working out the layout in sysfs to make it more intuitive. Also sorry for the somewhat rough and ready nature of the attached
patch (against 2.6.26-rc4)

Ring buffer design is a large part of the attached patch. I'm not sure if I am going about this the right way. Basically, we need ring buffers with almost no write latency but can waste plenty of time reading from them (in general case - we do however want reading the last available value to be fast). What is there works, but probably has at least a few nasty corner cases that I haven't prevented.

Interfaces (these are per device) - at somepoint a procfs interface similar
to that used in the input subsystem would make device querying simpler.

Sysfs - Parameter Control - gain / offsets etc
State control, turn interrupts on and off etc. Interrupt control parameters (threshold etc)
Ring buffer parameters as relevant (currently fixed) Individual input reading (acceleration values here) Minor numbers for various chrdevs associated with this device.

chrdev- 3 types of chrdev at the moment
Ring buffer events
Ring buffer access (currently ripping data off the buffer only) Interrupt events - for lis3l02dq these are only threshold breaks

Functionality yet to be implemented.
Polled based capture (use a peroidic timer if available)

Hardware ring buffering for devices that support it (two level ring
buffer -
hard and soft may be appropriate)

A chrdev for polling of whole device (with timestamps etc).

Composite interrupt handling (some devices allow logical combinations of different interrupt signals to be used as the trigger condition).

Documenation ;)

Cleaner solution to data alignment in the ring buffer (currently I'm
cheating
and manually doing it)

Lots lots more....

Anyhow, all comments welcome. Can anyone think of a better name? (I'm not keen on industrialio. It's too long if nothing else!
It will do as a working title for now)

Thanks,

--

Jonathan Cameron

Documenation ;)

From Documentation/CodingStyle:

Sysfs - Parameter Control - gain / offsets etc
State control, turn interrupts on and off etc.

Anyhow, all comments welcome. Can anyone think of a better name? (I'm not keen on industrialio. It's too long if nothing else!
It will do as a working title for now)

Quoted 2 lines · Jonathan Cameron

Sysfs - Parameter Control - gain / offsets etc
State control, turn interrupts on and off etc.

As in turn userspace [interrupt] event notification on and off? I would have thought it'd be the kernel driver's responsibility to turn the device's interrupt generation on and off according to needs for data/events etc.

I know this is in a rough state but a few comments anyway. First, there are heaps of casts-of-void-pointers (eg casts of kmalloc returns) which are superfluous and hard readability 'coz you have to split the line to fit in 80cols.

And hardcoded type-size assumptions everywhere. Don't be scared of sizeof ;-)

Quoted 3 lines

Anyhow, all comments welcome. Can anyone think of a better name? (I'm not keen on industrialio. It's too long if nothing else!
It will do as a working title for now)

I don't mind industrial io but as a function prefix, iio works better. I can't see it being used elsewhere.

also:

drivers/industrialio/accelerometer/lis3l02dq.c +17 -0

+/* As the ring buffer contents are device dependent this functionality
+ * must remain part of the driver and not the ring buffer subsystem */
+static ssize_t
+lis3l02dq_read_accel_from_ring(struct industrialio_ring_buffer *ring,
+			       int element, char *buf)
+{
+	int val, ret, len;
+	uint16_t temp;
+	char *data, *datalock;
+
+	data = kmalloc(8, GFP_KERNEL);
+	if (data == NULL) {
+		ret = -ENOMEM;
+		goto error_ret;
+	}
+	ret = industrialio_read_last_from_ring(ring, data);
+	datalock = data + 2*element;

I haven't looked deeply at the ringbuffer code but can you guarantee that later elements are at higher addresses than the lower ones? As in, can one datum in the the ring buffer wrap to the beginning again?

drivers/industrialio/accelerometer/lis3l02dq.c +1 -0

+	kfree(data);

You free the data before you use it? Though you are using it through a different pointer below. I wouldn't be scared of allocating 8 bytes on the stack rather than kmalloc'ing (unless you expect this to be called in a deep callchain)

drivers/industrialio/accelerometer/lis3l02dq.c +3 -0

+	temp = (((uint16_t)((datalock[1]))) << 8)
+		| (uint16_t)(datalock[0]);
+	val = *((int16_t *)(&temp));

All this data/datalock/bitshuffle nonsense would be nicer if you just used structs and unions, yeah?

union channel {
	char data[2];
	int16_t val;
}

Incidentally, is there much that your ringbuffer can do which kfifo can't? Apart from having a bunch of extra nice accessor-helpers sitting on the top.

Overall looking good and useful, can't wait 'till it's done :-)

Quoted 9 lines · Ben Nizette

Quoted 2 lines · Jonathan Cameron

Sysfs - Parameter Control - gain / offsets etc
State control, turn interrupts on and off etc.

As in turn userspace [interrupt] event notification on and off? I would have thought it'd be the kernel driver's responsibility to turn the device's interrupt generation on and off according to needs for data/events etc.

Ok, there is a division here between interrupt handling on the host side which indeed should be turned on and off transparently by the driver and actually telling the sensor which interrupts to generate. In a sense this is simply a case of terminology and what is actually being requested is event notifications (which then match with those sent up to userspace).

Quoted 21 lines

also:

drivers/industrialio/accelerometer/lis3l02dq.c +17 -0

+/* As the ring buffer contents are device dependent this functionality
+ * must remain part of the driver and not the ring buffer subsystem */
+static ssize_t
+lis3l02dq_read_accel_from_ring(struct industrialio_ring_buffer *ring,
+			       int element, char *buf)
+{
+	int val, ret, len;
+	uint16_t temp;
+	char *data, *datalock;
+
+	data = kmalloc(8, GFP_KERNEL);
+	if (data == NULL) {
+		ret = -ENOMEM;
+		goto error_ret;
+	}
+	ret = industrialio_read_last_from_ring(ring, data);
+	datalock = data + 2*element;

Quoted 3 lines

I haven't looked deeply at the ringbuffer code but can you guarantee that later elements are at higher addresses than the lower ones? As in, can one datum in the the ring buffer wrap to the beginning again?

At the moment the ring buffer has to be a whole number of datums big. I'm inclined to keep it way and move more towards dynamic allocation such that it is true than to try handling split data reading sets.

Quoted 7 lines

drivers/industrialio/accelerometer/lis3l02dq.c +1 -0

+	kfree(data);

You free the data before you use it? Though you are using it through a different pointer below. I wouldn't be scared of allocating 8 bytes on the stack rather than kmalloc'ing (unless you expect this to be called in a deep callchain)

Ouch. That's an out and out bug!

Quoted 5 lines

drivers/industrialio/accelerometer/lis3l02dq.c +3 -0

+	temp = (((uint16_t)((datalock[1]))) << 8)
+		| (uint16_t)(datalock[0]);
+	val = *((int16_t *)(&temp));

Quoted 7 lines

All this data/datalock/bitshuffle nonsense would be nicer if you just used structs and unions, yeah?

union channel {
	char data[2];
	int16_t val;
}

Good point, I'd forgotten you could do that with unions.

drivers/industrialio/accelerometer/lis3l02dq.c line 468

Quoted 13 lines

struct datum {
	union channel elements[3];
}

or something.

drivers/industrialio/accelerometer/lis3l02dq.c +6 -0

+	len = sprintf(buf, "ring %d\n", val);
+
+	return len;
+error_ret:
+	return ret;
+}

Good approach, I'll switch to that.

Quoted 1 line

Quoted 3 lines

Incidentally, is there much that your ringbuffer can do which kfifo can't? Apart from having a bunch of extra nice accessor-helpers sitting on the top.

Not sure, I'll look into it.

Quoted 2 lines

Overall looking good and useful, can't wait 'till it's done :-)

Thanks for the comments.

Jonathan

Quoted 5 lines

Quoted 4 lines

union channel {
	char data[2];
	int16_t val;
}

Good point, I'd forgotten you could do that with unions.

Cool, just watch endianness of course :-)

Quoted 4 lines

Quoted 3 lines

Incidentally, is there much that your ringbuffer can do which kfifo can't? Apart from having a bunch of extra nice accessor-helpers sitting on the top.

Not sure, I'll look into it.

kfifo won't be a drop in replacement, it's just a very simple ring fifo. I suspect your higher level ring buffer accessors and allocators could live on top of it though.