Dear All,
Here is another iteration of the ABI spec for IIO with changes made in response
to http://lkml.org/lkml/2010/1/20/195 and
http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few other
general tidy ups.
If there are no major issues raised, we may begin working on the move to this
ABI shortly on the basis any minor changes can always get cleaned up before
those patches merge. I'll also be doing a formal version of this file for
in kernel documentation once things are fairly stable with all of the information
not relevant to this discussion.
Changes since v1:
* iio is now a bus with directory changes resulting in this document.
* moved to in0_raw etc for voltage sensors to avoid confusion with a completely
different ABI from hwmon. Jean made the point that we shouldn't take this to
far, but as things currently stand there is no disadvantage in this name change.
* dropped freefall event for now. More discussions need to be had on this and in
a straight IIO world we normally won't care about this one anyway.
* 'device' naming changed for the various subsidiary devices so as make the
interconnections more obvious. I haven't tried implementing this yet, but I
think the small amount of pain involved is worth it for increased clarity.
The only exception is triggers where the connections are not specified as a
given trigger may not have and IIO device associated with it. Anyone suggest
a scheme for this? (see about 10 lines below to clarify what I mean here!)
* As conversion of the max1363 driver over to a consistent scan_element interface
will mean that these will only apply to the ring buffer (rather than direct
capture), scan_elements is moved into the ring buffer device directory.
* Switch ring for simply buffer as it might be a fifo or other buffer form instead.
At times I may have suppressed links that would be created by the tree of
devices. In the flat base directory a given driver can now create the following:
device[n]
device[n]:ring
device[n]:ring:access
device[n]:ring:event
device[n]:event[m]
trigger[o]
Which correspond to
device[n]
device[n]:ring
device[n]:ring:access
device[n]:ring:event
device[n]:event[m]
trigger[o]
Hence we still meet the unique naming requirements but have a much clearer
direct means fo understanding the resulting tree.
---
I have take liberties with not specifying obvious equivalents of scale etc
for all the channel types.
There are probably countless error in here. Please point any out you come
across. This file may well need breaking up into sysfs-class-iio-in, accel
etc so as to keep it manageable. Note this is not intended to obey the ABI
spec well. It will be cleaned up before submission and all the other
required information added.
What: /sys/bus/iio/devices/device[n]
Description:
Hardware chip or device accessed by on communication port.
Corresponds to a grouping of sensor channels.
What: /sys/bus/iio/devices/trigger[n]
Description:
An event driven driver of data capture to an in kernel buffer.
May be provided by a device driver that also has an IIO device
based on hardware generated events (e.g. data ready) or
provided by a separate driver for other hardware (e.g.
periodic timer, gpio or high resolution timer).
Contains trigger type specific elements. These do not
generalize well and hence are not documented in this file.
What: /sys/bus/iio/devices/device[n]:buffer
Description:
Link to /sys/class/iio/device[n]/device[n]:buffer. n indicates the
device with which this buffer buffer is associated.
What: /sys/.../device[n]/name
Description:
Description of the physical chip / device. Typically a part
number.
What: /sys/.../device[n]/in[_name][m]_raw
Description:
Raw (unscaled no bias removal etc) voltage measurement from
channel m. name is used in special cases where this does
not correspond to externally available input (e.g. supply
voltage monitoring in which case the file is in_supply_raw).
What: /sys/.../device[n]/in[_name][m]_offset
Description:
If known for a device, offset to be added to in[m]_raw prior
to scaling by volt[m]_scale in order to obtain voltage in
millivolts. Not present if the offset is always 0 or unknown.
If m is not present, then voltage offset applies to all in
channels. May be writable if a variable offset is controlled
by the device. Note that this is different to calibbias which
is for devices that apply offsets to compensate for variation
between different instances of the part, typically adjusted by
using some hardware supported calibration procedure.
What: /sys/.../device[n]/in[_name][m]_offset_available
Description:
If a small number of discrete offset values are available, this
will be a space separated list. If these are independant (but
options the same) for individual offsets then m should not be
present.
What: /sys/.../device[n]/in[_name][m]_offset_[min|max]
Description:
If a more or less continuous range of voltage offsets are supported
then these specify the minimum and maximum. If shared by all
in channels then m is not present.
What: /sys/.../device[n]/in[_name][m]_calibbias
Description:
Hardware applied calibration offset. (assumed to fix production
inaccuracies)
What /sys/.../device[n]/in[_name][m]_calibscale
Description:
Hardware applied calibration scale factor. (assumed to fix production
inaccuracies)
What: /sys/.../device[n]/in[_name][m]_scale
Description:
If known for a device, scale to be applied to volt[m]_raw post
addition of volt[m]_offset in order to obtain the measured voltage
in millivolts. If shared across all in channels then m is not present.
What: /sys/.../device[n]/in[m]-in[o]_raw
Description:
Raw (unscaled) differential voltage measurement equivalent to
channel m - channel o where these channel numbers apply to the physically
equivalent inputs when non differential readings are separately available.
In differential only parts, then all that is required is a consistent
labelling.
What: /sys/.../device[n]/accel[_x|_y|_z][m]_raw
Description:
Acceleration in direction x, y or z (may be arbitrarily assigned
but should match other such assignments on device)
channel m (not present if only one accelerometer channel at
this orientation). Has all of the equivalent parameters as per in[m].
Units after application of scale and offset are m/s^2.
What: /sys/.../device[n]/gyro[_x|_y|_z][m]_raw
Description:
Angular velocity about axis x, y or z (may be arbitrarily assigned)
channel m (not present if only one gyroscope at this orientation).
Data converted by application of offset then scale to
radians per second. Has all the equivalent parameters as per in[m].
What: /sys/.../device[n]/mag[_x|_y|_z][m]_raw
Description:
Magnetic field along axis x, y or z (may be arbitrarily assigned)
channel m (not present if only one magnetometer at this orientation).
Data converted by application of offset then scale to Gauss
Has all the equivalent modifiers as per in[m].
What: /sys/.../device[n]/device[n]:event[m]
Description:
Configuration of which hardware generated events are passed up to
userspace. Some of these are a bit complex to generalize so this
section is a work in progress.
What: /sys/.../device[n]:event[m]/dev
Description:
major:minor character device numbers for the event line.
Taking accel_x0 as an example
What: /sys/.../device[n]:event[m]/accel_x0_thresh[_high|_low]
Description:
Event generated when accel_x0 passes a threshold in correction direction
(or stays beyond one). If direction isn't specified, either triggers it.
Note driver will assume last p events requested are enabled where p is
however many it supports. So if you want to be sure you have
set what you think you have, check the contents of these. Drivers
may have to buffer any parameters so that they are consistent when a
given event type is enabled a future point (and not those for whatever
alarm was previously enabled).
What: /sys/.../device[n]:event[m]/accel_x0_roc[_high|_low]
Description:
Same as above but based on the first differential of the value.
What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_period
Description:
A period of time (microsecs) for which the condition must be broken
before an interrupt is triggered. Applies to all alarms if type is not
specified.
What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_value
Description:
The actual value of the threshold in raw device units obtained by
reverse application of scale and offset to the acceleration in m/s^2.
What: /sys/.../device[n]:buffer/scan_elements
Description:
Directory containing interfaces for elements that will be captured
for a single triggered sample set in the buffer.
What: /sys/.../device[n]:buffer/scan_elements/[m]_accel_x0_en
Description:
Scan element control for triggered data capture. m implies the
ordering within the buffer. Next the type is specified with
modifier and channel number as per the sysfs single channel
access above.
What: /sys/.../device[n]:buffer/scan_elements/accel[_x0]_precision
Description:
Scan element precision within the buffer. Note that the
data alignment must restrictions must be read from within
buffer to work out full data alignment for data read
via buffer_access chrdev. _x0 dropped if shared across all
acceleration channels.
What: /sys/.../device[n]:buffer/scan_elements/accel[_x0]_shift
Description:
A bit shift (to right) that must be applied prior to
extracting the bits specified by accel[_x0]_precision.
What: /sys/.../device[n]:buffer/device[n]:buffer:event/dev
Description:
Buffer for device n event character device major:minor numbers.
What: /sys/.../device[n]:buffer/device[n]:buffer:access/dev
Description:
Buffer for device n access character device o major:minor numbers.
What: /sys/.../device[n]:buffer/trigger
Description:
The name of the trigger source being used, as per string given
in /sys/class/iio/trigger[n]/name.
What: /sys/.../device[n]:buffer/length
Description:
Number of scans contained by the buffer.
What: /sys/.../device[n]:buffer/bps
Description:
Bytes per scan. Due to alignment fun, the scan may be larger
than implied directly by the scan_element parameters.
What: /sys/.../device[n]:buffer/enable
Description:
Actually start the buffer capture up. Will start trigger
if first device and appropriate.
What: /sys/.../device[n]:buffer/alignment
Description:
Minimum data alignment. Scan elements larger than this are aligned
to the nearest power of 2 times this. (may not be true in weird
hardware buffers that pack data well)
So an example, adis16350
/sys/bus/iio/devices contains
device0
accel_scale (applies to all accel channels)
accel_x_raw (the raw reading)
accel_x_calibbias (calibration value - in reg XACCEL_OFF
accel_x_raw_offset assumed to be 0 so not provided).
accel_y_raw
accel_y_calibbias
accel_z_raw
accel_z_calibbias
gyro_scale
gyro_x_raw
gyro_x_calibbias
gyro_y_raw
gyro_y_calibbias
gyro_z_raw
gyro_z_calbbias
in0_raw
in0_scale
in_supply_raw
in_supply_scale
temp_gyrox_raw (These are somewhat unusual!)
temp_scale
temp_offset
temp_gyroy_raw
temp_gyroz_raw
frequency (applies even when trigger not running, so a device parameter
rather than one for the data ready trigger)
//some stuff that may not generalise...
auto_bias_calib
auto_bias_calib_precision
restore_factory
gyro_compensate_accel
accel_origin_align
device0:buffer/
current_trigger
device0:buffer:access
dev
device0:buffer:event
dev
length
bps
buffer_enable
alignment
scan_elements
00_in_supply_en
01_gyro_x_en
02_gyro_y_en
03_gyro_z_en
04_accel_x_en
05_accel_y_en
06_accel_z_en
07_temp_gyrox_en
08_temp_gyroy_en
09_temp_gyroz_en
10_in0_en
gyro_prescision
accel_precision
in0_precision
in_supply_precision
temp_precision
device0:event0/
dev
accel_x_thresh_high_en
accel_x_thresh_high_value
accel_x_thresh_high_period
accel_x_thresh_low_en
accel_x_thresh_low_value
accel_x_thresh_low_period
accel_x_roc_high_en
accel_x_roc_high_value
accel_x_roc_high_period
accel_x_roc_low_en
accel_x_roc_low_value
accel_x_roc_low_period
//etc. This may seem overkill but this the only option that I
//can think of that generalizes well. Other suggestions welcome!
//device specific (may generalize)
filtered
trigger0/ (adis16350 is providing a data ready trigger)
name
//there are no other parameters here as the datardy frequency is dependent
//on how device is configured.
On Fri, Feb 05, 2010 at 06:21:16PM +0000, Jonathan Cameron wrote:
> Dear All,
>
> Here is another iteration of the ABI spec for IIO with changes made in response
> to http://lkml.org/lkml/2010/1/20/195 and
> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few other
> general tidy ups.
>
> If there are no major issues raised, we may begin working on the move to this
> ABI shortly on the basis any minor changes can always get cleaned up before
> those patches merge. I'll also be doing a formal version of this file for
> in kernel documentation once things are fairly stable with all of the information
> not relevant to this discussion.
>
> Changes since v1:
>
> * iio is now a bus with directory changes resulting in this document.
> * moved to in0_raw etc for voltage sensors to avoid confusion with a completely
> different ABI from hwmon. Jean made the point that we shouldn't take this to
> far, but as things currently stand there is no disadvantage in this name change.
> * dropped freefall event for now. More discussions need to be had on this and in
> a straight IIO world we normally won't care about this one anyway.
> * 'device' naming changed for the various subsidiary devices so as make the
> interconnections more obvious. I haven't tried implementing this yet, but I
> think the small amount of pain involved is worth it for increased clarity.
> The only exception is triggers where the connections are not specified as a
> given trigger may not have and IIO device associated with it. Anyone suggest
> a scheme for this? (see about 10 lines below to clarify what I mean here!)
> * As conversion of the max1363 driver over to a consistent scan_element interface
> will mean that these will only apply to the ring buffer (rather than direct
> capture), scan_elements is moved into the ring buffer device directory.
> * Switch ring for simply buffer as it might be a fifo or other buffer form instead.
>
> At times I may have suppressed links that would be created by the tree of
> devices. In the flat base directory a given driver can now create the following:
>
> device[n]
> device[n]:ring
> device[n]:ring:access
> device[n]:ring:event
> device[n]:event[m]
> trigger[o]
>
> Which correspond to
>
> device[n]
> device[n]:ring
> device[n]:ring:access
> device[n]:ring:event
> device[n]:event[m]
>
> trigger[o]
>
> Hence we still meet the unique naming requirements but have a much clearer
> direct means fo understanding the resulting tree.
>
> ---
> I have take liberties with not specifying obvious equivalents of scale etc
> for all the channel types.
>
>
> There are probably countless error in here. Please point any out you come
> across. This file may well need breaking up into sysfs-class-iio-in, accel
> etc so as to keep it manageable. Note this is not intended to obey the ABI
> spec well. It will be cleaned up before submission and all the other
> required information added.
>
How about current and power measurement devices? I have an TI INA209
chip which I've written a hwmon driver for, but the hwmon guys don't
want to accept the driver upstream for the following reasons, and
suggest IIO instead.
1) it is sensitive enough to measure voltage in uV. This makes a huge
difference when calculating current measurements, which I currently do
in userspace with lm-sensors. The sense resistor is very likely to have
a different value depending on the application the chip is used in. On
my board, we have 5 of these chip, with 3 different resistor values.
2) it has "output pin enables". You can program an overcurrent limit
into the device. When the current being drawn exceeds this limit, it
drives an output pin so the power supply can be shut off quickly. In my
case, it is wired to an LTC4215 hot swap controller.
Ira
> What: /sys/bus/iio/devices/device[n]
> Description:
> Hardware chip or device accessed by on communication port.
> Corresponds to a grouping of sensor channels.
>
> What: /sys/bus/iio/devices/trigger[n]
> Description:
> An event driven driver of data capture to an in kernel buffer.
> May be provided by a device driver that also has an IIO device
> based on hardware generated events (e.g. data ready) or
> provided by a separate driver for other hardware (e.g.
> periodic timer, gpio or high resolution timer).
> Contains trigger type specific elements. These do not
> generalize well and hence are not documented in this file.
>
> What: /sys/bus/iio/devices/device[n]:buffer
> Description:
> Link to /sys/class/iio/device[n]/device[n]:buffer. n indicates the
> device with which this buffer buffer is associated.
>
> What: /sys/.../device[n]/name
> Description:
> Description of the physical chip / device. Typically a part
> number.
>
> What: /sys/.../device[n]/in[_name][m]_raw
> Description:
> Raw (unscaled no bias removal etc) voltage measurement from
> channel m. name is used in special cases where this does
> not correspond to externally available input (e.g. supply
> voltage monitoring in which case the file is in_supply_raw).
>
> What: /sys/.../device[n]/in[_name][m]_offset
> Description:
> If known for a device, offset to be added to in[m]_raw prior
> to scaling by volt[m]_scale in order to obtain voltage in
> millivolts. Not present if the offset is always 0 or unknown.
> If m is not present, then voltage offset applies to all in
> channels. May be writable if a variable offset is controlled
> by the device. Note that this is different to calibbias which
> is for devices that apply offsets to compensate for variation
> between different instances of the part, typically adjusted by
> using some hardware supported calibration procedure.
>
> What: /sys/.../device[n]/in[_name][m]_offset_available
> Description:
> If a small number of discrete offset values are available, this
> will be a space separated list. If these are independant (but
> options the same) for individual offsets then m should not be
> present.
>
> What: /sys/.../device[n]/in[_name][m]_offset_[min|max]
> Description:
> If a more or less continuous range of voltage offsets are supported
> then these specify the minimum and maximum. If shared by all
> in channels then m is not present.
>
> What: /sys/.../device[n]/in[_name][m]_calibbias
> Description:
> Hardware applied calibration offset. (assumed to fix production
> inaccuracies)
>
> What /sys/.../device[n]/in[_name][m]_calibscale
> Description:
> Hardware applied calibration scale factor. (assumed to fix production
> inaccuracies)
>
> What: /sys/.../device[n]/in[_name][m]_scale
> Description:
> If known for a device, scale to be applied to volt[m]_raw post
> addition of volt[m]_offset in order to obtain the measured voltage
> in millivolts. If shared across all in channels then m is not present.
>
> What: /sys/.../device[n]/in[m]-in[o]_raw
> Description:
> Raw (unscaled) differential voltage measurement equivalent to
> channel m - channel o where these channel numbers apply to the physically
> equivalent inputs when non differential readings are separately available.
> In differential only parts, then all that is required is a consistent
> labelling.
>
> What: /sys/.../device[n]/accel[_x|_y|_z][m]_raw
> Description:
> Acceleration in direction x, y or z (may be arbitrarily assigned
> but should match other such assignments on device)
> channel m (not present if only one accelerometer channel at
> this orientation). Has all of the equivalent parameters as per in[m].
> Units after application of scale and offset are m/s^2.
>
> What: /sys/.../device[n]/gyro[_x|_y|_z][m]_raw
> Description:
> Angular velocity about axis x, y or z (may be arbitrarily assigned)
> channel m (not present if only one gyroscope at this orientation).
> Data converted by application of offset then scale to
> radians per second. Has all the equivalent parameters as per in[m].
>
> What: /sys/.../device[n]/mag[_x|_y|_z][m]_raw
> Description:
> Magnetic field along axis x, y or z (may be arbitrarily assigned)
> channel m (not present if only one magnetometer at this orientation).
> Data converted by application of offset then scale to Gauss
> Has all the equivalent modifiers as per in[m].
>
> What: /sys/.../device[n]/device[n]:event[m]
> Description:
> Configuration of which hardware generated events are passed up to
> userspace. Some of these are a bit complex to generalize so this
> section is a work in progress.
>
> What: /sys/.../device[n]:event[m]/dev
> Description:
> major:minor character device numbers for the event line.
>
> Taking accel_x0 as an example
>
> What: /sys/.../device[n]:event[m]/accel_x0_thresh[_high|_low]
> Description:
> Event generated when accel_x0 passes a threshold in correction direction
> (or stays beyond one). If direction isn't specified, either triggers it.
> Note driver will assume last p events requested are enabled where p is
> however many it supports. So if you want to be sure you have
> set what you think you have, check the contents of these. Drivers
> may have to buffer any parameters so that they are consistent when a
> given event type is enabled a future point (and not those for whatever
> alarm was previously enabled).
>
> What: /sys/.../device[n]:event[m]/accel_x0_roc[_high|_low]
> Description:
> Same as above but based on the first differential of the value.
>
>
> What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_period
> Description:
> A period of time (microsecs) for which the condition must be broken
> before an interrupt is triggered. Applies to all alarms if type is not
> specified.
>
> What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_value
> Description:
> The actual value of the threshold in raw device units obtained by
> reverse application of scale and offset to the acceleration in m/s^2.
>
> What: /sys/.../device[n]:buffer/scan_elements
> Description:
> Directory containing interfaces for elements that will be captured
> for a single triggered sample set in the buffer.
>
> What: /sys/.../device[n]:buffer/scan_elements/[m]_accel_x0_en
> Description:
> Scan element control for triggered data capture. m implies the
> ordering within the buffer. Next the type is specified with
> modifier and channel number as per the sysfs single channel
> access above.
>
> What: /sys/.../device[n]:buffer/scan_elements/accel[_x0]_precision
> Description:
> Scan element precision within the buffer. Note that the
> data alignment must restrictions must be read from within
> buffer to work out full data alignment for data read
> via buffer_access chrdev. _x0 dropped if shared across all
> acceleration channels.
>
> What: /sys/.../device[n]:buffer/scan_elements/accel[_x0]_shift
> Description:
> A bit shift (to right) that must be applied prior to
> extracting the bits specified by accel[_x0]_precision.
>
> What: /sys/.../device[n]:buffer/device[n]:buffer:event/dev
> Description:
> Buffer for device n event character device major:minor numbers.
>
> What: /sys/.../device[n]:buffer/device[n]:buffer:access/dev
> Description:
> Buffer for device n access character device o major:minor numbers.
>
> What: /sys/.../device[n]:buffer/trigger
> Description:
> The name of the trigger source being used, as per string given
> in /sys/class/iio/trigger[n]/name.
>
> What: /sys/.../device[n]:buffer/length
> Description:
> Number of scans contained by the buffer.
>
> What: /sys/.../device[n]:buffer/bps
> Description:
> Bytes per scan. Due to alignment fun, the scan may be larger
> than implied directly by the scan_element parameters.
>
> What: /sys/.../device[n]:buffer/enable
> Description:
> Actually start the buffer capture up. Will start trigger
> if first device and appropriate.
>
> What: /sys/.../device[n]:buffer/alignment
> Description:
> Minimum data alignment. Scan elements larger than this are aligned
> to the nearest power of 2 times this. (may not be true in weird
> hardware buffers that pack data well)
>
>
>
> So an example, adis16350
>
> /sys/bus/iio/devices contains
>
> device0
>
> accel_scale (applies to all accel channels)
> accel_x_raw (the raw reading)
> accel_x_calibbias (calibration value - in reg XACCEL_OFF
> accel_x_raw_offset assumed to be 0 so not provided).
> accel_y_raw
> accel_y_calibbias
>
> accel_z_raw
> accel_z_calibbias
>
> gyro_scale
> gyro_x_raw
> gyro_x_calibbias
>
> gyro_y_raw
> gyro_y_calibbias
>
> gyro_z_raw
> gyro_z_calbbias
>
> in0_raw
> in0_scale
> in_supply_raw
> in_supply_scale
>
> temp_gyrox_raw (These are somewhat unusual!)
> temp_scale
> temp_offset
> temp_gyroy_raw
> temp_gyroz_raw
>
> frequency (applies even when trigger not running, so a device parameter
> rather than one for the data ready trigger)
>
> //some stuff that may not generalise...
> auto_bias_calib
> auto_bias_calib_precision
> restore_factory
> gyro_compensate_accel
> accel_origin_align
>
> device0:buffer/
> current_trigger
> device0:buffer:access
> dev
> device0:buffer:event
> dev
> length
> bps
> buffer_enable
> alignment
> scan_elements
> 00_in_supply_en
> 01_gyro_x_en
> 02_gyro_y_en
> 03_gyro_z_en
> 04_accel_x_en
> 05_accel_y_en
> 06_accel_z_en
> 07_temp_gyrox_en
> 08_temp_gyroy_en
> 09_temp_gyroz_en
> 10_in0_en
> gyro_prescision
> accel_precision
> in0_precision
> in_supply_precision
> temp_precision
> device0:event0/
> dev
> accel_x_thresh_high_en
> accel_x_thresh_high_value
> accel_x_thresh_high_period
>
> accel_x_thresh_low_en
> accel_x_thresh_low_value
> accel_x_thresh_low_period
>
> accel_x_roc_high_en
> accel_x_roc_high_value
> accel_x_roc_high_period
>
> accel_x_roc_low_en
> accel_x_roc_low_value
> accel_x_roc_low_period
>
> //etc. This may seem overkill but this the only option that I
> //can think of that generalizes well. Other suggestions welcome!
>
> //device specific (may generalize)
> filtered
>
>
> trigger0/ (adis16350 is providing a data ready trigger)
> name
> //there are no other parameters here as the datardy frequency is dependent
> //on how device is configured.
>
Hi Ira,
>> There are probably countless error in here. Please point any out you come
>> across. This file may well need breaking up into sysfs-class-iio-in, accel
>> etc so as to keep it manageable. Note this is not intended to obey the ABI
>> spec well. It will be cleaned up before submission and all the other
>> required information added.
>>
>
> How about current and power measurement devices?
We aren't applying any hard limits to what we will cover by IIO. At the moment
the limits tend to be more precisely set by what is not adequately covered else
where than the other way around. The other category of things we are including
tend to require facilities that IIO provides (buffering / event infrastructure)
that are not provided as is by an apparently more appropriate subsystem and
where the alternate subsystems.
For reference, Analog Devices have already suggested they will be using IIO
for a couple of energy meeting ICs which will have some similarities.
https://docs.blackfin.uclinux.org/doku.php?id=adi_peripheral_drivers
For reference, we have a fairly dirty wiki page for IIO keeping track of devices
people are working on (or at least have and plan to work on for some of the ones
I'm listing!)
http://sourceforge.net/apps/mediawiki/iioutils/index.php?title=Device_List
As I don't have any equivalent devices in my development set, I'm happy to leave
those who do to hammer out any relevant details of naming etc as long as the
result fits nicely with the bits that are already being defined.
> I have an TI INA209
Interesting bit of kit. The rest of my comments are based on a quick data sheet
browse, so please point out anything I have misunderstood or simply missed!
> chip which I've written a hwmon driver for, but the hwmon guys don't
> want to accept the driver upstream for the following reasons, and
> suggest IIO instead.
>
> 1) it is sensitive enough to measure voltage in uV. This makes a huge
> difference when calculating current measurements, which I currently do
> in userspace with lm-sensors. The sense resistor is very likely to have
> a different value depending on the application the chip is used in. On
> my board, we have 5 of these chip, with 3 different resistor values.
To clarify things, do these resistors tend to specified accurately enough
on a per design basis, or are we at the level where we want to individually
calibrate individual devices? The question is relevant to whether it makes
sense to specify these resistors as platform data or where else these values
need to be.
>
> 2) it has "output pin enables". You can program an overcurrent limit
> into the device. When the current being drawn exceeds this limit, it
> drives an output pin so the power supply can be shut off quickly. In my
> case, it is wired to an LTC4215 hot swap controller.
Interesting setup.. If those output pin enables were routed to standard
interrupts (which clearly defeats the point!) then we could simply handle
them as event lines in IIO. Here we have a rather convoluted situation
where they act as hardware triggers of another device. The first question
is whether it makes sense to make this know to the operating system, or whether
we effectively just ignore the physical link and configure the two interactive
devices appropriately (obviously we need to provide the means to do this!).
For the rest of this discussion, let us ignore the exact case you have here
and consider it as a more generic interrupt. Obviously your current driver
has support for much if not all of what follows!
So things this device has:
* Current measurement. For this we probably want to match naming with hwmon (no
reason not to) with raw and conversion info as per in0_raw etc below. I note
we also have a controllable PGA so some of the conversion factors will be rw.
* trigger option for conversion. (IIO handles this fine)
* Peak-hold registers. This one is new to us, so we will need to think of a suitable
naming convention, but I'd guess reading these via sysfs will be adequate?
* Critical comparitor control. Although much faster, these are basically threshold
event detectors so we can use equivalents of the events described below.
* Lots of filtering controls. Until we get a feel for how generalizable things like
this are, we will keep them driver specific and out of the ABI spec.
* The smbus alert stuff should work fine as an event source. I remember seeing
some patches for support in i2c from David Brownell. We probably want to chase
these up for this device driver.
* The single control handling data accuracy 8/10/12bit then averaging may take some thought!
So in conclusion, yes, this device falls within the scope of IIO but there are a number
of ABI elements that will need discussion. Feel free to get that discussion going
here, by proposing the ABI you want!
Jonathan
On Sat, 06 Feb 2010 13:59:33 +0000, Jonathan Cameron wrote:
> * The smbus alert stuff should work fine as an event source. I remember seeing
> some patches for support in i2c from David Brownell. We probably want to chase
> these up for this device driver.
FWIW, I'm reworking David's patches right now and should have something
ready for public consumption by the end of tomorrow.
--
Jean Delvare
On Sat, Feb 06, 2010 at 01:59:33PM +0000, Jonathan Cameron wrote:
> Hi Ira,
>
> >> There are probably countless error in here. Please point any out you come
> >> across. This file may well need breaking up into sysfs-class-iio-in, accel
> >> etc so as to keep it manageable. Note this is not intended to obey the ABI
> >> spec well. It will be cleaned up before submission and all the other
> >> required information added.
> >>
> >
> > How about current and power measurement devices?
> We aren't applying any hard limits to what we will cover by IIO. At the moment
> the limits tend to be more precisely set by what is not adequately covered else
> where than the other way around. The other category of things we are including
> tend to require facilities that IIO provides (buffering / event infrastructure)
> that are not provided as is by an apparently more appropriate subsystem and
> where the alternate subsystems.
>
> For reference, Analog Devices have already suggested they will be using IIO
> for a couple of energy meeting ICs which will have some similarities.
>
> https://docs.blackfin.uclinux.org/doku.php?id=adi_peripheral_drivers
>
> For reference, we have a fairly dirty wiki page for IIO keeping track of devices
> people are working on (or at least have and plan to work on for some of the ones
> I'm listing!)
>
> http://sourceforge.net/apps/mediawiki/iioutils/index.php?title=Device_List
>
> As I don't have any equivalent devices in my development set, I'm happy to leave
> those who do to hammer out any relevant details of naming etc as long as the
> result fits nicely with the bits that are already being defined.
> > I have an TI INA209
> Interesting bit of kit. The rest of my comments are based on a quick data sheet
> browse, so please point out anything I have misunderstood or simply missed!
> > chip which I've written a hwmon driver for, but the hwmon guys don't
> > want to accept the driver upstream for the following reasons, and
> > suggest IIO instead.
> >
> > 1) it is sensitive enough to measure voltage in uV. This makes a huge
> > difference when calculating current measurements, which I currently do
> > in userspace with lm-sensors. The sense resistor is very likely to have
> > a different value depending on the application the chip is used in. On
> > my board, we have 5 of these chip, with 3 different resistor values.
> To clarify things, do these resistors tend to specified accurately enough
> on a per design basis, or are we at the level where we want to individually
> calibrate individual devices? The question is relevant to whether it makes
> sense to specify these resistors as platform data or where else these values
> need to be.
On my device, they're very accurate. I think putting them in platform
data would be fine. Right now I specify them in conversions performed by
libsensors. Across my 20 (soon to be 150) boards, the measurements all
agree to within a few mV / mA.
> >
> > 2) it has "output pin enables". You can program an overcurrent limit
> > into the device. When the current being drawn exceeds this limit, it
> > drives an output pin so the power supply can be shut off quickly. In my
> > case, it is wired to an LTC4215 hot swap controller.
>
> Interesting setup.. If those output pin enables were routed to standard
> interrupts (which clearly defeats the point!) then we could simply handle
> them as event lines in IIO. Here we have a rather convoluted situation
> where they act as hardware triggers of another device. The first question
> is whether it makes sense to make this know to the operating system, or whether
> we effectively just ignore the physical link and configure the two interactive
> devices appropriately (obviously we need to provide the means to do this!).
>
Ok, I sort-of lied here. They're really routed through an FPGA state
machine so I can capture other information when they trigger. But you're
correct, putting them on a standard interrupt line defeats the point. I
use the INA209's in high-current power supplies to turn off the power
before burning up big (expensive) data processing FPGA's.
Some info about the board, if you want to have a look:
http://www.mmarray.org/~dwh/carma_board/index.html
> For the rest of this discussion, let us ignore the exact case you have here
> and consider it as a more generic interrupt. Obviously your current driver
> has support for much if not all of what follows!
>
> So things this device has:
>
> * Current measurement. For this we probably want to match naming with hwmon (no
> reason not to) with raw and conversion info as per in0_raw etc below. I note
> we also have a controllable PGA so some of the conversion factors will be rw.
Yep. This chip's current measurement engine requires programming the
chip with a circuit-specific value before it works. This is the
"calibration register" in the datasheet. Instead of inventing a new
hwmon sysfs attribute for this register, I reported the voltage "at the
pins of the chip" and had libsensors do the conversion in userspace.
> * trigger option for conversion. (IIO handles this fine)
I don't use anything fancy here. I just put the ADC in continuous
measurement mode and let it do its thing.
> * Peak-hold registers. This one is new to us, so we will need to think of a suitable
> naming convention, but I'd guess reading these via sysfs will be adequate?
I'd match the hwmon naming here too. They've got tempX_{highest,lowest}
as well as powerX_input_{highest,lowest}. I used inX_input_highest in my
hwmon INA209 driver.
> * Critical comparitor control. Although much faster, these are basically threshold
> event detectors so we can use equivalents of the events described below.
Yep, these are the things that turn off the power supplies quickly on
overcurrent conditions. Other than voltage and current measurement, this
is the feature I need most.
> * Lots of filtering controls. Until we get a feel for how generalizable things like
> this are, we will keep them driver specific and out of the ABI spec.
Sounds good. I just programmed the filters to a reasonable value that
seems to weed out any problems.
> * The smbus alert stuff should work fine as an event source. I remember seeing
> some patches for support in i2c from David Brownell. We probably want to chase
> these up for this device driver.
I actually don't use SMBAlert at all, since AFAIK it isn't supported
through the Linux i2c stack yet. I see that Jean is working on this. I
do have the SMBAlert lines hooked to generic interrupt lines on my
processor.
> * The single control handling data accuracy 8/10/12bit then averaging may take some thought!
>
I don't change this either. I just leave it set to the power-on default,
and let the chip run.
> So in conclusion, yes, this device falls within the scope of IIO but there are a number
> of ABI elements that will need discussion. Feel free to get that discussion going
> here, by proposing the ABI you want!
>
Thanks for taking the time to respond,
Ira
On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
> Dear All,
>
> Here is another iteration of the ABI spec for IIO with changes made
> in response to http://lkml.org/lkml/2010/1/20/195 and
> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
> other general tidy ups.
>
> If there are no major issues raised, we may begin working on the move
> to this ABI shortly on the basis any minor changes can always get
> cleaned up before those patches merge. I'll also be doing a formal
> version of this file for in kernel documentation once things are
> fairly stable with all of the information not relevant to this
> discussion.
>
> Changes since v1:
>
> * iio is now a bus with directory changes resulting in this document.
> * moved to in0_raw etc for voltage sensors to avoid confusion with
> a completely different ABI from hwmon. Jean made the point that
> we shouldn't take this to far, but as things currently stand there
> is no disadvantage in this name change.
> * dropped freefall event for now. More discussions need to be had on this
> and in a straight IIO world we normally won't care about this one anyway.
> * 'device' naming changed for the various subsidiary devices so as make
> the interconnections more obvious. I haven't tried implementing this
> yet, but I think the small amount of pain involved is worth it for
> increased clarity. The only exception is triggers where the connections
> are not specified as a given trigger may not have and IIO device
> associated with it. Anyone suggest a scheme for this? (see about 10
> lines below to clarify what I mean here!)
> * As conversion of the max1363 driver over to a consistent scan_element
> interface will mean that these will only apply to the ring buffer
> (rather than direct capture), scan_elements is moved into the ring
> buffer device directory.
> * Switch ring for simply buffer as it might be a fifo or other buffer
> form instead.
>
> At times I may have suppressed links that would be created by the tree of
> devices. In the flat base directory a given driver can now create the
> following:
>
> device[n]
> device[n]:ring
> device[n]:ring:access
> device[n]:ring:event
> device[n]:event[m]
> trigger[o]
>
What exists today still requires a copy_[to|from]_user when using the ring
buffer (and then another cache_flush if you are dma'ing things). These seems
pretty expensive and will consume extra cycles that will limit throughput.
Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
system could avoid some of the above overhead? (This is what we had to do for
some other drivers - which were able to handle a 40 MSample/second data
processed by userspace for a soft radio).
?
On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
>> Here is another iteration of the ABI spec for IIO with changes made
>> in response to http://lkml.org/lkml/2010/1/20/195 and
>> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
>> other general tidy ups.
>>
>> If there are no major issues raised, we may begin working on the move
>> to this ABI shortly on the basis any minor changes can always get
>> cleaned up before those patches merge. I'll also be doing a formal
>> version of this file for in kernel documentation once things are
>> fairly stable with all of the information not relevant to this
>> discussion.
>>
>> Changes since v1:
>>
>> * iio is now a bus with directory changes resulting in this document.
>> * moved to in0_raw etc for voltage sensors to avoid confusion with
>> a completely different ABI from hwmon. Jean made the point that
>> we shouldn't take this to far, but as things currently stand there
>> is no disadvantage in this name change.
>> * dropped freefall event for now. More discussions need to be had on this
>> and in a straight IIO world we normally won't care about this one anyway.
>> * 'device' naming changed for the various subsidiary devices so as make
>> the interconnections more obvious. I haven't tried implementing this
>> yet, but I think the small amount of pain involved is worth it for
>> increased clarity. The only exception is triggers where the connections
>> are not specified as a given trigger may not have and IIO device
>> associated with it. Anyone suggest a scheme for this? (see about 10
>> lines below to clarify what I mean here!)
>> * As conversion of the max1363 driver over to a consistent scan_element
>> interface will mean that these will only apply to the ring buffer
>> (rather than direct capture), scan_elements is moved into the ring
>> buffer device directory.
>> * Switch ring for simply buffer as it might be a fifo or other buffer
>> form instead.
>>
>> At times I may have suppressed links that would be created by the tree of
>> devices. In the flat base directory a given driver can now create the
>> following:
>>
>> device[n]
>> device[n]:ring
>> device[n]:ring:access
>> device[n]:ring:event
>> device[n]:event[m]
>> trigger[o]
>>
>
> What exists today still requires a copy_[to|from]_user when using the ring
> buffer (and then another cache_flush if you are dma'ing things). These seems
> pretty expensive and will consume extra cycles that will limit throughput.
>
> Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
> system could avoid some of the above overhead? (This is what we had to do for
> some other drivers - which were able to handle a 40 MSample/second data
> processed by userspace for a soft radio).
does sysfs currently support mmap-ing of files in there ?
-mike
On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> > On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
> >> Here is another iteration of the ABI spec for IIO with changes made
> >> in response to http://lkml.org/lkml/2010/1/20/195 and
> >> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
> >> other general tidy ups.
> >>
> >> If there are no major issues raised, we may begin working on the move
> >> to this ABI shortly on the basis any minor changes can always get
> >> cleaned up before those patches merge. ??I'll also be doing a formal
> >> version of this file for in kernel documentation once things are
> >> fairly stable with all of the information not relevant to this
> >> discussion.
> >>
> >> Changes since v1:
> >>
> >> * iio is now a bus with directory changes resulting in this document.
> >> * moved to in0_raw etc for voltage sensors to avoid confusion with
> >> ?? a completely different ABI from hwmon. ??Jean made the point that
> >> ?? we shouldn't take this to far, but as things currently stand there
> >> ?? is no disadvantage in this name change.
> >> * dropped freefall event for now. More discussions need to be had on this
> >> ?? and in a straight IIO world we normally won't care about this one anyway.
> >> * 'device' naming changed for the various subsidiary devices so as make
> >> ?? the interconnections more obvious. ??I haven't tried implementing this
> >> ?? yet, but I think the small amount of pain involved is worth it for
> >> ?? increased clarity. The only exception is triggers where the connections
> >> ?? are not specified as a given trigger may not have and IIO device
> >> ?? associated with it. ??Anyone suggest a scheme for this? (see about 10
> >> ?? lines below to clarify what I mean here!)
> >> * As conversion of the max1363 driver over to a consistent scan_element
> >> ?? interface will mean that these will only apply to the ring buffer
> >> ?? (rather than direct capture), scan_elements is moved into the ring
> >> ?? buffer device directory.
> >> * Switch ring for simply buffer as it might be a fifo or other buffer
> >> ?? form instead.
> >>
> >> At times I may have suppressed links that would be created by the tree of
> >> devices. In the flat base directory a given driver can now create the
> >> following:
> >>
> >> device[n]
> >> device[n]:ring
> >> device[n]:ring:access
> >> device[n]:ring:event
> >> device[n]:event[m]
> >> trigger[o]
> >>
> >
> > What exists today still requires a copy_[to|from]_user when using the ring
> > buffer (and then another cache_flush if you are dma'ing things). These seems
> > pretty expensive and will consume extra cycles that will limit throughput.
> >
> > Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
> > system could avoid some of the above overhead? (This is what we had to do for
> > some other drivers - which were able to handle a 40 MSample/second data
> > processed by userspace for a soft radio).
>
> does sysfs currently support mmap-ing of files in there ?
For binary files, yes. If you are going to use mmap, use a character
device node instead please, that's not what sysfs is for.
thanks,
greg k-h
On 02/16/10 02:49, Greg KH wrote:
> On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
>> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
>>> On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
>>>> Here is another iteration of the ABI spec for IIO with changes made
>>>> in response to http://lkml.org/lkml/2010/1/20/195 and
>>>> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
>>>> other general tidy ups.
>>>>
>>>> If there are no major issues raised, we may begin working on the move
>>>> to this ABI shortly on the basis any minor changes can always get
>>>> cleaned up before those patches merge. ??I'll also be doing a formal
>>>> version of this file for in kernel documentation once things are
>>>> fairly stable with all of the information not relevant to this
>>>> discussion.
>>>>
>>>> Changes since v1:
>>>>
>>>> * iio is now a bus with directory changes resulting in this document.
>>>> * moved to in0_raw etc for voltage sensors to avoid confusion with
>>>> ?? a completely different ABI from hwmon. ??Jean made the point that
>>>> ?? we shouldn't take this to far, but as things currently stand there
>>>> ?? is no disadvantage in this name change.
>>>> * dropped freefall event for now. More discussions need to be had on this
>>>> ?? and in a straight IIO world we normally won't care about this one anyway.
>>>> * 'device' naming changed for the various subsidiary devices so as make
>>>> ?? the interconnections more obvious. ??I haven't tried implementing this
>>>> ?? yet, but I think the small amount of pain involved is worth it for
>>>> ?? increased clarity. The only exception is triggers where the connections
>>>> ?? are not specified as a given trigger may not have and IIO device
>>>> ?? associated with it. ??Anyone suggest a scheme for this? (see about 10
>>>> ?? lines below to clarify what I mean here!)
>>>> * As conversion of the max1363 driver over to a consistent scan_element
>>>> ?? interface will mean that these will only apply to the ring buffer
>>>> ?? (rather than direct capture), scan_elements is moved into the ring
>>>> ?? buffer device directory.
>>>> * Switch ring for simply buffer as it might be a fifo or other buffer
>>>> ?? form instead.
>>>>
>>>> At times I may have suppressed links that would be created by the tree of
>>>> devices. In the flat base directory a given driver can now create the
>>>> following:
>>>>
>>>> device[n]
>>>> device[n]:ring
>>>> device[n]:ring:access
>>>> device[n]:ring:event
>>>> device[n]:event[m]
>>>> trigger[o]
>>>>
>>>
>>> What exists today still requires a copy_[to|from]_user when using the ring
>>> buffer (and then another cache_flush if you are dma'ing things). These seems
>>> pretty expensive and will consume extra cycles that will limit throughput.
>>>
>>> Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
>>> system could avoid some of the above overhead? (This is what we had to do for
>>> some other drivers - which were able to handle a 40 MSample/second data
>>> processed by userspace for a soft radio).
>>
>> does sysfs currently support mmap-ing of files in there ?
>
> For binary files, yes. If you are going to use mmap, use a character
> device node instead please, that's not what sysfs is for.
All the buffer access is done via character device nodes anyway.
For anyone entering the discussion at this point:
Only really simple IIO drivers (for typically very slow devices)
are principally accessed through sysfs. For these fast devices we
probably wouldn't provide that route at all, merely using sysfs to
describe the parameters of the device and buffer being used.
Jonathan
On Tue 16 Feb 2010 06:03, Jonathan Cameron pondered:
> On 02/16/10 02:49, Greg KH wrote:
> > On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
> >> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> >>> [snip]
> >>> What exists today still requires a copy_[to|from]_user when using
> >>> the ring buffer (and then another cache_flush if you are dma'ing
> >>> things). These seems pretty expensive and will consume extra cycles
> >>> that will limit throughput.
> >>>
> >>> Any thoughts to a mmaped interface directly to the IIO ring buffer,
> >>> so the system could avoid some of the above overhead? (This is what
> >>> we had to do for some other drivers - which were able to handle a 40
> >>> MSample/second data processed by userspace for a soft radio).
> >>
> >> does sysfs currently support mmap-ing of files in there ?
> >
> > For binary files, yes. If you are going to use mmap, use a character
> > device node instead please, that's not what sysfs is for.
> All the buffer access is done via character device nodes anyway.
>
> For anyone entering the discussion at this point:
> Only really simple IIO drivers (for typically very slow devices)
> are principally accessed through sysfs. For these fast devices we
> probably wouldn't provide that route at all, merely using sysfs to
> describe the parameters of the device and buffer being used.
Can we be a little more specific - what in your mind is "very slow"?
and "fast"?
Is it designated by samples per second? (and bits per sample doesn't matter?)
or is it the result (bits per sample * samples per second/8 == bytes/second?)
Many people I know would call a 1Mega sample per second converter very slow,
but the kernel handling a memcpy of a continuous 2Mbyte/second (16-bits per
sample), stream seems a little wasteful.
Thanks
-Robin
On 02/16/10 19:18, Robin Getz wrote:
> On Tue 16 Feb 2010 06:03, Jonathan Cameron pondered:
>> On 02/16/10 02:49, Greg KH wrote:
>>> On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
>>>> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
>>>>> [snip]
>>>>> What exists today still requires a copy_[to|from]_user when using
>>>>> the ring buffer (and then another cache_flush if you are dma'ing
>>>>> things). These seems pretty expensive and will consume extra cycles
>>>>> that will limit throughput.
>>>>>
>>>>> Any thoughts to a mmaped interface directly to the IIO ring buffer,
>>>>> so the system could avoid some of the above overhead? (This is what
>>>>> we had to do for some other drivers - which were able to handle a 40
>>>>> MSample/second data processed by userspace for a soft radio).
>>>>
>>>> does sysfs currently support mmap-ing of files in there ?
>>>
>>> For binary files, yes. If you are going to use mmap, use a character
>>> device node instead please, that's not what sysfs is for.
>> All the buffer access is done via character device nodes anyway.
>>
>> For anyone entering the discussion at this point:
>> Only really simple IIO drivers (for typically very slow devices)
>> are principally accessed through sysfs. For these fast devices we
>> probably wouldn't provide that route at all, merely using sysfs to
>> describe the parameters of the device and buffer being used.
>
> Can we be a little more specific - what in your mind is "very slow"?
> and "fast"?
>
> Is it designated by samples per second? (and bits per sample doesn't matter?)
> or is it the result (bits per sample * samples per second/8 == bytes/second?)
>
> Many people I know would call a 1Mega sample per second converter very slow,
> but the kernel handling a memcpy of a continuous 2Mbyte/second (16-bits per
> sample), stream seems a little wasteful.
I think we want to keep this fairly fuzzy. Basically I'd envision people only
writing drivers for devices to the level they need. A sysfs only interface
is always going to be the starting point for the majority of drivers. If nothing
else it provides a simple means of sanity checking that the device is working
as expected. At that level the subsystem is more or less an equivalent of
hwmon and similar systems. As such a driver is only marginally more complex
to write.
If, like I have for my apps, (and indeed you probably want to support) people
have a need for handling mid rates (fuzzily perhaps starting at a few
hundred bytes per sec) then they will probably want to use some buffering
and it the extra copy of not using mmaping won't really mater them, but if
it is there it would certainly be nice.
At the higher rates then, as you say, that memcpy is going to start to become
an issue. Exactly where is going to be very dependent on the platform. So
in the ideal world there will be no costs to having a mmapped buffer and we
would simply use such a 'perfect' buffer for both the 'mid' and 'high' rate devices.
Until we have an implementation I'm not sure what issues it will result in.
Obviously there will always be IIO buffers where mmapping isn't possible,
(hardware buffers via a serial bus for example), but I'd love to see support
where we can. I think the trick to this might be to push forward breaking the
current hard connections between particular drivers and a given buffer
implementation to give us the flexibility to play with different options.
Frankly if we can get the functionality of my highly dubious ring implementation
with mmaping and a cleaner implementation it would be a great advancement.
That is to say if we can have a buffering structure with minimal (ideally no)
locking, that is scalable to radically different sizes (as appropriate for the
range of data rates we are dealing with) and supports notification (without polling)
of buffer thresholds being passed then I will be a very happy bunny indeed.
The events stuff may not be relevant to all applications and this might make life
easier for a high performance buffer, but then we would definitely need to maintain
a version with this capability for cases like extremely variable rate triggering.
On a similar note, we also ideally need to have a buffer implementation that allows
for direct dma transfers into the buffer so as to cut down on the copies currently
present there. I was interested to see the recent proposals to add this functionality
to kfifo. This will be complex to implement for some devices where there are annoying
things like status bytes kicking around, but that can be a problem for the individual
drivers (and appropriate interactions with the underlying buses).
(kfifo reference: http://lkml.org/lkml/2010/1/27/139 )
So in conclusion. Lets deliberately keep things vague!
Jonathan