* [RFC] Staging:IIO: New ABI @ 2010-01-20 15:13 Jonathan Cameron 2010-01-20 15:37 ` Greg KH 0 siblings, 1 reply; 17+ messages in thread From: Jonathan Cameron @ 2010-01-20 15:13 UTC (permalink / raw) To: LKML Cc: Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Greg KH, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder Dear All, An extensive conversation with Manuel Stahl that grew out of his work on an ADIS16400 driver and the userspace IIO tools at iioutils.sourceforge.net showed that there were a number of significant short comings in the current IIO ABI. Some of these were simply things that have never been pinned down, others are down to silly issues with how the code has developed. Hence Manuel and I have drawn up a new ABI specification. With hindsight we should probably have held the entire conversation publicly but this document will hopefully act as summary. Please forgive the flagrant abuse of syntax in large parts of this file. This will all be cleaned up before a formal submission. At this stage what we are after is comments on the actual IIO sysfs ABI. There are doubtlessly unclear sections and elements we have forgotten completely so if you know of something that is missing (along with a concrete example of where it is needed, please do point it out!) To avoid an insanely long ABI spec, I've suppressed fields that are not of interest to this discussion and not specified some items that are similar in purpose to those given for volt channels. All comments welcome. One area of extreme complexity currently is that of event handling and specifically how come up with a consistent generalizable specification when there are so many different options. Comments / suggestions on this are particularly welcome! As ever, if people could forward / cc anyone how they think may be interested that would be great. The current cc list is based on a fairly rapid dash through previous threads. What: /sys/class/iio/device[n] Description: Hardware chip or device accessed by on communication port. Corresponds to a grouping of sensor channels. What: /sys/class/iio/trigger[n] Description: An event driven driver of data capture to an in kernel buffer. May be provided a device driver that also has an IIO device based on hardware generated events (e.g. data ready) or provided by other hardware (e.g. periodic timer or gpio) Contains trigger type specific elements. These do not generalize well. What: /sys/class/iio/ring_buffer[m] Description: Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer numbering may not match that of device as some devices do not have ring buffers. What: /sys/class/iio/device[n]/name Description: Description of the physical chip / device. Typically a part number. What: /sys/class/iio/device[n]/volt_[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). What: /sys/class/iio/device[n]/volt_[name][m]_offset Description: If known for a device, offset to be added to volt[m]_raw prior to scaling by volt[m]_scale in order to obtain voltage in Volts. Not present if the offset is always 0 or unknown. If m is not present, then voltage offset applies to all volt 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. What: /sys/class/iio/device[n]/volt_[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/class/iio/device[n]/volt_[name][m]_offset_[min|max] Description: If a more or less continuous range of voltage offsets are supported then this specifies the minimum / maximum. If shared by all volt channels then m is not present. What: /sys/class/iio/device[n]/volt_[name][m]_calibbias Description: Hardware applied calibration offset. (assumed to fix production inaccuracies) What /sys/class/iio/device[n]/volt_[name][m]_calibscale Description: Hardware applied calibration scale factor. (assumed to fix production inaccuracies) What: /sys/class/iio/device[n]/volt_[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 volts. If shared across all voltage channels the m is not present. What: /sys/class/iio/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 volt[m]. Units after application of scale and offset are m/s^2. What: /sys/class/iio/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 volt[m]. What: /sys/class/iio/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 volt[m]. What: /sys/class/iio/device[n]/pressure[m]_raw Description: Barometric pressure //Lots more to add along a similar vain. What: /sys/class/iio/device[n]/event_line[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/class/iio/device[n]/event_line[m]/dev Description: major:minor character device numbers. Again taking accel_x0 as example and serious liberties with ABI spec. What: /sys/.../event_line[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/.../event_line[m]/accel_x0_roc[_high|_low] Description: Same as above but based on the first differential of the value. What: /sys/.../event_line[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/.../event_line[m]/accel_x0[_thresh|_roc][_high|_low]_value Description: The actual value of the threshold either in raw device units obtained by reverse application of scale and offfset to the acceleration in m/s^2. What: /sys/.../event_line[m]/free_fall Description: Common hardware event in accelerometers. Takes no parameters. There are many other weird and wonderful event types that we'll deal with as and when. Taking accel_x0 for example of next section. What: /sys/class/iio/device[n]/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/class/iio/device[n]/scan_elements/accel[_x0]_precision Description: Scan element precision within the ring buffer. Note that the data alignment must restrictions must be read from in ring_buffer to work out full data alignment for data read via ring_access chrdev. _x0 dropped if shared across all acceleration channels. What: /sys/class/iio/device[n]/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/class/iio/device[n]/ring_buffer[m] Description: Ring buffer specific parameters separate. Some are influenced by scan_elements. What: /sys/.../ring_buffer[m]/ring_event[o]/dev Description: Ring buffer m event character device o major:minor numbers. What: /sys/.../ring_buffer[m]/ring_access[o]/dev Description: Ring buffer m access character device o major:minor numbers. What: /sys/.../ring_buffer[m]/trigger Description: The name of the trigger source being used, as per string given in /sys/class/iio/trigger[n]/name. What: /sys/.../ring_buffer[m]/length Description: Number of scans contained by the buffer. What: /sys/.../ring_buffer[m]/bps Description: Bytes per scan. Due to alignment fun, the scan may be larger than implied directly by the scan_element parameters. What: /sys/.../ring_buffer[m]/enable Description: Actually start the ring buffer capture up. Will start trigger if first device and appropriate. What: /sys/.../ring_buffer[m]/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 ring buffers that pack data well) So an example, adis16350 /sys/class/iio 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_x_calibbias gyro_z_raw gyro_z_calbbias volt_0_raw volt_0_scale volt_supply_raw volt_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) //some stuff that may not generalise... auto_bias_calib auto_bias_calib_precision restore_factory gyro_compensate_accel accel_origin_align //associated trigger can be navigated to via device directory. Also the default //trigger will be set correctly. Not in ring_buffer as that directory may become //dependent on live configurable ring buffer types. (spurious argument?) trigger/ current_trigger ring_buffer0/ ring_access0 dev ring_event0 dev length bps ring_enable alignment scan_elements 00_volt_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_volt_0_en gyro_prescision accel_precision volt_0_precision volt_supply_precision temp_precision event_line0/ 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. (I think it makes more sense in device). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 15:13 [RFC] Staging:IIO: New ABI Jonathan Cameron @ 2010-01-20 15:37 ` Greg KH 2010-01-20 16:40 ` Kay Sievers 2010-01-20 16:53 ` Jonathan Cameron 0 siblings, 2 replies; 17+ messages in thread From: Greg KH @ 2010-01-20 15:37 UTC (permalink / raw) To: Jonathan Cameron Cc: LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Wed, Jan 20, 2010 at 03:13:40PM +0000, Jonathan Cameron wrote: > What: /sys/class/iio/device[n] > Description: > Hardware chip or device accessed by on communication port. > Corresponds to a grouping of sensor channels. > > What: /sys/class/iio/trigger[n] > Description: > An event driven driver of data capture to an in kernel buffer. > May be provided a device driver that also has an IIO device > based on hardware generated events (e.g. data ready) or > provided by other hardware (e.g. periodic timer or gpio) > Contains trigger type specific elements. These do not > generalize well. > > > What: /sys/class/iio/ring_buffer[m] > Description: > Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer > numbering may not match that of device as some devices do not > have ring buffers. Why is this link needed? Why can't you just look in the device directory for a ring buffer? And wouldn't the ring buffer be 1..n for every device? They shouldn't be "unique" for all iio devices, that would be wierd. > What: /sys/class/iio/device[n]/name > Description: > Description of the physical chip / device. Typically a part > number. > > What: /sys/class/iio/device[n]/volt_[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). So what would 'name' be? > What: /sys/class/iio/device[n]/volt_[name][m]_offset > Description: > If known for a device, offset to be added to volt[m]_raw prior > to scaling by volt[m]_scale in order to obtain voltage in > Volts. Not present if the offset is always 0 or unknown. > If m is not present, then voltage offset applies to all volt > 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. > > What: /sys/class/iio/device[n]/volt_[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/class/iio/device[n]/volt_[name][m]_offset_[min|max] > Description: > If a more or less continuous range of voltage offsets are supported > then this specifies the minimum / maximum. If shared by all > volt channels then m is not present. > > What: /sys/class/iio/device[n]/volt_[name][m]_calibbias > Description: > Hardware applied calibration offset. (assumed to fix production > inaccuracies) > > What /sys/class/iio/device[n]/volt_[name][m]_calibscale > Description: > Hardware applied calibration scale factor. (assumed to fix production > inaccuracies) > > What: /sys/class/iio/device[n]/volt_[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 volts. If shared across all voltage channels the m is not present. For all of these voltage measurements, why use something different from what the kernel already supports for the existing hardware monitoring devices? There is already a well-defined api for these things. > What: /sys/class/iio/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 volt[m]. > Units after application of scale and offset are m/s^2. Shouldn't this just use the existing input accelerometer interface so as to keep userspace sane? > What: /sys/class/iio/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 volt[m]. Same as above, I think we already have an api for this. > What: /sys/class/iio/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 volt[m]. > > What: /sys/class/iio/device[n]/pressure[m]_raw > Description: > Barometric pressure > > //Lots more to add along a similar vain. Again, look at the existing apis, if we don't have the exiting units and types, we can always add them, instead of making up new ones burried in the iio class stuff. > What: /sys/class/iio/device[n]/event_line[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/class/iio/device[n]/event_line[m]/dev > Description: > major:minor character device numbers. No, don't bury devices down a level in sysfs, that's not ok. Actually, I think it would take you a lot of work to get this to properly work on the implementation side :) If event_lines need device nodes, then they should be real devices. Actually, all of this looks like it needs to be a bus, not a class, if you are having this many different types of things hanging off of them. Have you thought about that instead? It would make your code a lot easier in the end. > Again taking accel_x0 as example and serious liberties with ABI spec. > > What: /sys/.../event_line[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/.../event_line[m]/accel_x0_roc[_high|_low] > Description: > Same as above but based on the first differential of the value. > > > What: /sys/.../event_line[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/.../event_line[m]/accel_x0[_thresh|_roc][_high|_low]_value > Description: > The actual value of the threshold either in raw device units > obtained by reverse application of scale and offfset to the > acceleration in m/s^2. Again, look at our existing apis, I think we already cover these types of things, don't create new ones please. > What: /sys/.../event_line[m]/free_fall > Description: > Common hardware event in accelerometers. Takes no parameters. I know we have this one already, please use it. > There are many other weird and wonderful event types that we'll deal with as and when. > > > Taking accel_x0 for example of next section. > > What: /sys/class/iio/device[n]/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/class/iio/device[n]/scan_elements/accel[_x0]_precision > Description: > Scan element precision within the ring buffer. Note that the > data alignment must restrictions must be read from in > ring_buffer to work out full data alignment for data read > via ring_access chrdev. _x0 dropped if shared across all > acceleration channels. > > What: /sys/class/iio/device[n]/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/class/iio/device[n]/ring_buffer[m] > Description: > Ring buffer specific parameters separate. Some are influenced > by scan_elements. > > What: /sys/.../ring_buffer[m]/ring_event[o]/dev > Description: > Ring buffer m event character device o major:minor numbers. Again, don't bury devices. Or if you are, use a bus, not a class, that's the wrong classification. thanks, greg k-h ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 15:37 ` Greg KH @ 2010-01-20 16:40 ` Kay Sievers 2010-01-20 16:53 ` Jonathan Cameron 1 sibling, 0 replies; 17+ messages in thread From: Kay Sievers @ 2010-01-20 16:40 UTC (permalink / raw) To: Greg KH Cc: Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Wed, Jan 20, 2010 at 16:37, Greg KH <greg@kroah.com> wrote: > On Wed, Jan 20, 2010 at 03:13:40PM +0000, Jonathan Cameron wrote: >> What: /sys/class/iio/ring_buffer[m] >> Description: >> Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer >> numbering may not match that of device as some devices do not >> have ring buffers. > > Why is this link needed? Why can't you just look in the device > directory for a ring buffer? And wouldn't the ring buffer be 1..n for > every device? They shouldn't be "unique" for all iio devices, that > would be wierd. I think with the hidden class kobject we successfully prevent any custom links from being created there. :) The class sysfs layout does not allow custom links added to its single directory, it confuses userspace. Jonathan, if you need anything like this, please consider using a "bus_type", which has the proper userspace interface. The "class" interface can not be extended to make such things possible. Thanks, Kay ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 15:37 ` Greg KH 2010-01-20 16:40 ` Kay Sievers @ 2010-01-20 16:53 ` Jonathan Cameron 2010-01-20 17:14 ` Kay Sievers 2010-01-22 20:47 ` Greg KH 1 sibling, 2 replies; 17+ messages in thread From: Jonathan Cameron @ 2010-01-20 16:53 UTC (permalink / raw) To: Greg KH Cc: Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder Hi Greg, > On Wed, Jan 20, 2010 at 03:13:40PM +0000, Jonathan Cameron wrote: >> What: /sys/class/iio/device[n] >> Description: >> Hardware chip or device accessed by on communication port. >> Corresponds to a grouping of sensor channels. >> >> What: /sys/class/iio/trigger[n] >> Description: >> An event driven driver of data capture to an in kernel buffer. >> May be provided a device driver that also has an IIO device >> based on hardware generated events (e.g. data ready) or >> provided by other hardware (e.g. periodic timer or gpio) >> Contains trigger type specific elements. These do not >> generalize well. >> >> >> What: /sys/class/iio/ring_buffer[m] >> Description: >> Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer >> numbering may not match that of device as some devices do not >> have ring buffers. > > Why is this link needed? Why can't you just look in the device > directory for a ring buffer? And wouldn't the ring buffer be 1..n for > every device? They shouldn't be "unique" for all iio devices, that > would be wierd. I'm a little unclear what you mean here (so my apologies if I'm misinterpreting!) A given IIO device will indeed have a either none or typically 1 ring buffers. They are not currently shared across devices. Aggregation if desired is done in userspace. Curiously enough there has been some argument in favour of a buffer per channel but that is a whole different issue. Reasons to have independent buffer per device: 1) Simplicity of handling a lot of data. Rates we are catering for go up to MSPs. 2) Low overheads. Using the interface given here userspace knows what is in the buffer so you simply store data, not headers which would be needed in shared buffers. (being able to do this is what a lot of the api below is about). 3) Applications do not desire aggregation of data from different sensors, or if they do this is better handled in user space where we can waste time figuring out data set alignment offline. There are cases where a trigger is shared across multiple devices, where it may make sense to share a ring buffer but the management of that is rather complex so has been left for now. e.g. How do you handle a case where a trigger is too fast for one of your two sensors so it misses a reading without every single reading requiring a header? (toy example of the fun that occurs!) Also note that in some cases the ring buffer is very much unique to the device: It is in hardware on it. (sca3000 for example) > >> What: /sys/class/iio/device[n]/name >> Description: >> Description of the physical chip / device. Typically a part >> number. >> >> What: /sys/class/iio/device[n]/volt_[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). > > So what would 'name' be? This is for a few device corner cases such as volt_supply_raw for the the adis16350 below. It can't really be used as a general purpose ADC so the idea was to separate it out. The vast majority of voltage channels would simply be numbered. There is an argument that, it might make sense to support this single parameter via hwmon, but then there are high end gyros where we would be grabbing the voltage, temperature and actual reading on each trigger so as to be able to compensate for the huge difference these can make to the resulting data. > >> What: /sys/class/iio/device[n]/volt_[name][m]_offset >> Description: >> If known for a device, offset to be added to volt[m]_raw prior >> to scaling by volt[m]_scale in order to obtain voltage in >> Volts. Not present if the offset is always 0 or unknown. >> If m is not present, then voltage offset applies to all volt >> 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. >> >> What: /sys/class/iio/device[n]/volt_[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/class/iio/device[n]/volt_[name][m]_offset_[min|max] >> Description: >> If a more or less continuous range of voltage offsets are supported >> then this specifies the minimum / maximum. If shared by all >> volt channels then m is not present. >> >> What: /sys/class/iio/device[n]/volt_[name][m]_calibbias >> Description: >> Hardware applied calibration offset. (assumed to fix production >> inaccuracies) >> >> What /sys/class/iio/device[n]/volt_[name][m]_calibscale >> Description: >> Hardware applied calibration scale factor. (assumed to fix production >> inaccuracies) >> >> What: /sys/class/iio/device[n]/volt_[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 volts. If shared across all voltage channels the m is not present. > > For all of these voltage measurements, why use something different from > what the kernel already supports for the existing hardware monitoring > devices? There is already a well-defined api for these things. Agreed. We did consider using in0 etc as per hwmon but decided that we were breaking sufficiently from the approach there (where the readings are always provided in microvolts iirc) that we could change the name to something that was a little more specific. I'm not overly tied to volt but the semantics are different enough here (with offsets and gain passed to userspace) that we may actually create confusion by mirroring that api. > >> What: /sys/class/iio/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 volt[m]. >> Units after application of scale and offset are m/s^2. > > Shouldn't this just use the existing input accelerometer interface so as > to keep userspace sane? Again, it comes down to whether we process the data or not. IIO is all about the ability to handle things fast. These sysfs interfaces are actually meant to mirror the chrdev ring buffer accesses which are the primary access point for higher end devices. A lot of the use cases are either interested in logging for later use, or algorithms that will run in the device units (sometime in integer arithmetic). Hence all conversion to sane units is left to userspace. The drivers merely provide sufficient information to do this conversion if it is desired. > >> What: /sys/class/iio/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 volt[m]. > > Same as above, I think we already have an api for this. > >> What: /sys/class/iio/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 volt[m]. >> >> What: /sys/class/iio/device[n]/pressure[m]_raw >> Description: >> Barometric pressure >> >> //Lots more to add along a similar vain. > > Again, look at the existing apis, if we don't have the exiting units and > types, we can always add them, instead of making up new ones burried in > the iio class stuff. I'm happy matching units (post conversion) but we really really don't want to convert in kernel. When you are dealing with a few hundred Hz this is fine, here it could mean halving your maximum sample rate or worse. Just consider the loops some hwmon drivers jump through to do this in integer arithmetic (I know, I wrote one of the most hideous ;) > >> What: /sys/class/iio/device[n]/event_line[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/class/iio/device[n]/event_line[m]/dev >> Description: >> major:minor character device numbers. > > No, don't bury devices down a level in sysfs, that's not ok. Actually, > I think it would take you a lot of work to get this to properly work on > the implementation side :) This bit of the documentation is indeed wrong (oops). These are members of the IIO class and so this is just a link (much like the event elements in input) created by making them in class iio with the device as a a parent. Again, application wise we aren't normally interested in aggregation so there is one (or more) of these per device. > > If event_lines need device nodes, then they should be real devices. (oops) The are ;) > > Actually, all of this looks like it needs to be a bus, not a class, if > you are having this many different types of things hanging off of them. > Have you thought about that instead? It would make your code a lot > easier in the end. That is definitely an option. The reason we didn't is more to do with following the most similar current case (input) than any particular preference. > >> Again taking accel_x0 as example and serious liberties with ABI spec. >> >> What: /sys/.../event_line[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/.../event_line[m]/accel_x0_roc[_high|_low] >> Description: >> Same as above but based on the first differential of the value. >> >> >> What: /sys/.../event_line[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/.../event_line[m]/accel_x0[_thresh|_roc][_high|_low]_value >> Description: >> The actual value of the threshold either in raw device units >> obtained by reverse application of scale and offfset to the >> acceleration in m/s^2. > > Again, look at our existing apis, I think we already cover these types > of things, don't create new ones please. I am not aware of these. Could you direct me to the current api? Also note that these aren't the actual alarms, merely a means of enabling the relevant event on the related event character device. > >> What: /sys/.../event_line[m]/free_fall >> Description: >> Common hardware event in accelerometers. Takes no parameters. > > I know we have this one already, please use it. Again, does it make sense to match api when the result is very different? The event infrastructure in IIO is much slimmer than that in input (this was one of the original reasons for not simply adding these things to input in the first place). This particular example is a bit unusual in that the current api (hwmon/lis3lv02d.c for example) handles this via a dedicated freefall character device. This doesn't really generalize to the more complex events handled here. To be honest this one doesn't really make sense in IIO's intended applications so it might be best to drop it entirely! We come back to an issue that turned up in the first discussions. There are cases where the possible use cases of some of these sensors differ so much that it may make sense to have completely separate drivers. > >> There are many other weird and wonderful event types that we'll deal with as and when. >> >> >> Taking accel_x0 for example of next section. >> >> What: /sys/class/iio/device[n]/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/class/iio/device[n]/scan_elements/accel[_x0]_precision >> Description: >> Scan element precision within the ring buffer. Note that the >> data alignment must restrictions must be read from in >> ring_buffer to work out full data alignment for data read >> via ring_access chrdev. _x0 dropped if shared across all >> acceleration channels. >> >> What: /sys/class/iio/device[n]/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/class/iio/device[n]/ring_buffer[m] >> Description: >> Ring buffer specific parameters separate. Some are influenced >> by scan_elements. >> >> What: /sys/.../ring_buffer[m]/ring_event[o]/dev >> Description: >> Ring buffer m event character device o major:minor numbers. > > Again, don't bury devices. Or if you are, use a bus, not a class, > that's the wrong classification. Cool, I'll look into making the change. What we really have here is a single conceptual device using a pair or character interfaces. Is a bus the right way to handle that? How about the following under a bus (this is for a single physical chip). device0 event0 (for physical events) ringaccess0 (actual device from which data is read) ringevent0 (associated event interface for the ring - ideally not aggregated with the event0) and sometimes: trigger0 Is that best way to go. Currently ringacces0 and ring event0 are grouped under ring_buffer0 but that was simply for the reason they are always matched. Thanks for the quick response! Jonathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 16:53 ` Jonathan Cameron @ 2010-01-20 17:14 ` Kay Sievers 2010-01-25 18:52 ` Jonathan Cameron 2010-01-22 20:47 ` Greg KH 1 sibling, 1 reply; 17+ messages in thread From: Kay Sievers @ 2010-01-20 17:14 UTC (permalink / raw) To: Jonathan Cameron Cc: Greg KH, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Wed, Jan 20, 2010 at 17:53, Jonathan Cameron <kernel@jic23.retrosnub.co.uk> wrote: >>> What: /sys/.../ring_buffer[m]/ring_event[o]/dev >>> Description: >>> Ring buffer m event character device o major:minor numbers. >> >> Again, don't bury devices. Or if you are, use a bus, not a class, >> that's the wrong classification. > Cool, I'll look into making the change. What we really have here > is a single conceptual device using a pair or character interfaces. Is a bus > the right way to handle that? "bus" and "class" are almost the same regarding the driver core, it should not make any difference for you. The "class" implementation is only a very simple case of a "bus" -- just with a pretty much broken userspace interface. :) Today, if we would start from scratch, there would be only something like /sys/subsystem in the layout of today's /sys/bus, and /sys/class, /sys/bus and /sys/block would not event exist. Tools like udev intentionally make no difference between them, and do not allow to distinguish between "class" or "bus". It's just called "susbsystem" there from the early days on. The "class" has only a single flat directory in /sys so it can never be extended with anything custom. No new subsystem should use the class interface anymore, all should use a "bus". I guess it's time to document that somewhere. :) Thanks, Kay ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 17:14 ` Kay Sievers @ 2010-01-25 18:52 ` Jonathan Cameron 0 siblings, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2010-01-25 18:52 UTC (permalink / raw) To: Kay Sievers Cc: Greg KH, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder Hi Kay, On 01/20/10 17:14, Kay Sievers wrote: > On Wed, Jan 20, 2010 at 17:53, Jonathan Cameron > <kernel@jic23.retrosnub.co.uk> wrote: >>>> What: /sys/.../ring_buffer[m]/ring_event[o]/dev >>>> Description: >>>> Ring buffer m event character device o major:minor numbers. >>> >>> Again, don't bury devices. Or if you are, use a bus, not a class, >>> that's the wrong classification. >> Cool, I'll look into making the change. What we really have here >> is a single conceptual device using a pair or character interfaces. Is a bus >> the right way to handle that? > > "bus" and "class" are almost the same regarding the driver core, it > should not make any difference for you. The "class" implementation is > only a very simple case of a "bus" -- just with a pretty much broken > userspace interface. :) > > Today, if we would start from scratch, there would be only something > like /sys/subsystem in the layout of today's /sys/bus, and /sys/class, > /sys/bus and /sys/block would not event exist. Tools like udev > intentionally make no difference between them, and do not allow to > distinguish between "class" or "bus". It's just called "susbsystem" > there from the early days on. > > The "class" has only a single flat directory in /sys so it can never > be extended with anything custom. No new subsystem should use the > class interface anymore, all should use a "bus". I guess it's time to > document that somewhere. :) > Thanks for clearing that up. IIO is now a bus, as you said the changes needed were very minor. I'll post the patch in a series with the ABI changes once the rest have settled down. The move to a bus has, in a sense (by looking at how others, particularly usb handle things), suggested that the 'bus element' naming could usefully provide more information about where things have come from. Perhaps the contents of /sys/bus/iio should be something like dev0 dev0:event0 [dev0:event1 etc] dev0:ring dev0:ring:access dev0:ring:event Note that dev0:ring only exists as a device to allow it to be used as a common parent for dev0:ring:access and dev0:ring:event, making the internal navigation a little more obvious along with providing a site for attributes that aren't specific to the ring access or event devices. This does lead to some slightly clunky naming inside directories, complicating user space access marginally dev0/dev0:ring/dev0:ring:access etc Is this added clarity something people feel is worth doing? Jonathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-20 16:53 ` Jonathan Cameron 2010-01-20 17:14 ` Kay Sievers @ 2010-01-22 20:47 ` Greg KH 2010-01-23 0:14 ` Dmitry Torokhov 2010-01-24 11:27 ` Jonathan Cameron 1 sibling, 2 replies; 17+ messages in thread From: Greg KH @ 2010-01-22 20:47 UTC (permalink / raw) To: Jonathan Cameron Cc: Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: > Hi Greg, > > > On Wed, Jan 20, 2010 at 03:13:40PM +0000, Jonathan Cameron wrote: > >> What: /sys/class/iio/device[n] > >> Description: > >> Hardware chip or device accessed by on communication port. > >> Corresponds to a grouping of sensor channels. > >> > >> What: /sys/class/iio/trigger[n] > >> Description: > >> An event driven driver of data capture to an in kernel buffer. > >> May be provided a device driver that also has an IIO device > >> based on hardware generated events (e.g. data ready) or > >> provided by other hardware (e.g. periodic timer or gpio) > >> Contains trigger type specific elements. These do not > >> generalize well. > >> > >> > >> What: /sys/class/iio/ring_buffer[m] > >> Description: > >> Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer > >> numbering may not match that of device as some devices do not > >> have ring buffers. > > > > Why is this link needed? Why can't you just look in the device > > directory for a ring buffer? And wouldn't the ring buffer be 1..n for > > every device? They shouldn't be "unique" for all iio devices, that > > would be wierd. > I'm a little unclear what you mean here (so my apologies if I'm misinterpreting!) > A given IIO device will indeed have a either none or typically 1 ring buffers. > They are not currently shared across devices. Aggregation if desired is done > in userspace. Ok, that's fine, but the name of those buffers do not have to be unique to all ring buffers in the system. Hm, oh yeah, they do, ok, nevermind, stupid me :) > >> What: /sys/class/iio/device[n]/name > >> Description: > >> Description of the physical chip / device. Typically a part > >> number. > >> > >> What: /sys/class/iio/device[n]/volt_[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). > > > > So what would 'name' be? > This is for a few device corner cases such as volt_supply_raw for the the > adis16350 below. It can't really be used as a general purpose ADC > so the idea was to separate it out. The vast majority of voltage channels > would simply be numbered. There is an argument that, it might make sense > to support this single parameter via hwmon, but then there are high end > gyros where we would be grabbing the voltage, temperature and actual reading > on each trigger so as to be able to compensate for the huge difference > these can make to the resulting data. But again, what would 'name' be? > >> What: /sys/class/iio/device[n]/volt_[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 volts. If shared across all voltage channels the m is not present. > > > > For all of these voltage measurements, why use something different from > > what the kernel already supports for the existing hardware monitoring > > devices? There is already a well-defined api for these things. > Agreed. We did consider using in0 etc as per hwmon but decided that we were > breaking sufficiently from the approach there (where the readings are always > provided in microvolts iirc) that we could change the name to something that > was a little more specific. I'm not overly tied to volt but the semantics > are different enough here (with offsets and gain passed to userspace) that > we may actually create confusion by mirroring that api. I really think you should merge with that api somehow. I understand that you don't want to do conversions in the kernel, so perhaps there could be some way to show this like you have described, that the hwmon interface could also use. That way userspace tools will work for all types of devices, and you don't have a custom interface just for these device. Unification is a good thing :) > >> What: /sys/class/iio/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 volt[m]. > >> Units after application of scale and offset are m/s^2. > > > > Shouldn't this just use the existing input accelerometer interface so as > > to keep userspace sane? > Again, it comes down to whether we process the data or not. IIO is all about > the ability to handle things fast. These sysfs interfaces are actually meant > to mirror the chrdev ring buffer accesses which are the primary access point > for higher end devices. A lot of the use cases are either interested in logging > for later use, or algorithms that will run in the device units (sometime in integer > arithmetic). Hence all conversion to sane units is left to userspace. The > drivers merely provide sufficient information to do this conversion if it > is desired. See above. I suggest working with the hwmon developers to add the "raw" type interface to their api making these able to be used there as well. > >> What: /sys/class/iio/device[n]/event_line[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/class/iio/device[n]/event_line[m]/dev > >> Description: > >> major:minor character device numbers. > > > > No, don't bury devices down a level in sysfs, that's not ok. Actually, > > I think it would take you a lot of work to get this to properly work on > > the implementation side :) > This bit of the documentation is indeed wrong (oops). These are members of the IIO > class and so this is just a link (much like the event elements in input) created > by making them in class iio with the device as a a parent. Again, application > wise we aren't normally interested in aggregation so there is one (or more) of these > per device. Ok. > > > > If event_lines need device nodes, then they should be real devices. > (oops) The are ;) Heh, that will not work, as Kay described :) > > Actually, all of this looks like it needs to be a bus, not a class, if > > you are having this many different types of things hanging off of them. > > Have you thought about that instead? It would make your code a lot > > easier in the end. > That is definitely an option. The reason we didn't is more to do with following > the most similar current case (input) than any particular preference. As Kay said, this should be a bus, and you should have devices attach to them, be it virtual or not. Or, you just tie into the hwmon interface which makes it much easier for you overall. > >> Again taking accel_x0 as example and serious liberties with ABI spec. > >> > >> What: /sys/.../event_line[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/.../event_line[m]/accel_x0_roc[_high|_low] > >> Description: > >> Same as above but based on the first differential of the value. > >> > >> > >> What: /sys/.../event_line[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/.../event_line[m]/accel_x0[_thresh|_roc][_high|_low]_value > >> Description: > >> The actual value of the threshold either in raw device units > >> obtained by reverse application of scale and offfset to the > >> acceleration in m/s^2. > > > > Again, look at our existing apis, I think we already cover these types > > of things, don't create new ones please. > I am not aware of these. Could you direct me to the current api? Also note that these > aren't the actual alarms, merely a means of enabling the relevant event on the related > event character device. Hm, I thought we had an accelerator interface somewhere... > >> What: /sys/.../event_line[m]/free_fall > >> Description: > >> Common hardware event in accelerometers. Takes no parameters. > > > > I know we have this one already, please use it. > > Again, does it make sense to match api when the result is very different? The event > infrastructure in IIO is much slimmer than that in input (this was one of the original > reasons for not simply adding these things to input in the first place). This particular > example is a bit unusual in that the current api (hwmon/lis3lv02d.c for example) handles > this via a dedicated freefall character device. This doesn't really generalize to the more > complex events handled here. To be honest this one doesn't really make sense in IIO's > intended applications so it might be best to drop it entirely! Yeah, a dedicated char device doesn't seem to make much sense either, but any unification you could find here would be nice. Even if it means the existing driver converts over to your new api :) > > Again, don't bury devices. Or if you are, use a bus, not a class, > > that's the wrong classification. > Cool, I'll look into making the change. What we really have here > is a single conceptual device using a pair or character interfaces. Is a bus > the right way to handle that? > > How about the following under a bus (this is for a single physical chip). > > device0 > event0 (for physical events) > ringaccess0 (actual device from which data is read) > ringevent0 (associated event interface for the ring - ideally not aggregated with the event0) > > and sometimes: > trigger0 > > Is that best way to go. Currently ringacces0 and ring event0 are > grouped under ring_buffer0 but that was simply for the reason they are > always matched. Yes, that would work, and make sense. thanks, greg k-h ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-22 20:47 ` Greg KH @ 2010-01-23 0:14 ` Dmitry Torokhov 2010-01-23 0:31 ` Greg KH 2010-01-24 11:27 ` Jonathan Cameron 1 sibling, 1 reply; 17+ messages in thread From: Dmitry Torokhov @ 2010-01-23 0:14 UTC (permalink / raw) To: Greg KH Cc: Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: > > I am not aware of these. Could you direct me to the current api? Also note that these > > aren't the actual alarms, merely a means of enabling the relevant event on the related > > event character device. > > Hm, I thought we had an accelerator interface somewhere... > Nope. And I am also interested in this since I am sittign on a bunch of accelerometers, magnetometers, etc drivers that are trying to plug into input sysbsystem and quite unsure what to do with them. It was OK whch HDAPS and friends when they were using input for secondary, toyish purposes, but these new drivers trying to use input devnts as primary API and I am unsure if it is the best solution. Accelerometer might be used as an input device but not always an input device. -- Dmitry ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-23 0:14 ` Dmitry Torokhov @ 2010-01-23 0:31 ` Greg KH 2010-01-26 9:34 ` Dmitry Torokhov 0 siblings, 1 reply; 17+ messages in thread From: Greg KH @ 2010-01-23 0:31 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: > > > I am not aware of these. Could you direct me to the current api? Also note that these > > > aren't the actual alarms, merely a means of enabling the relevant event on the related > > > event character device. > > > > Hm, I thought we had an accelerator interface somewhere... > > > > Nope. And I am also interested in this since I am sittign on a bunch of > accelerometers, magnetometers, etc drivers that are trying to plug into > input sysbsystem and quite unsure what to do with them. > > It was OK whch HDAPS and friends when they were using input for > secondary, toyish purposes, but these new drivers trying to use input > devnts as primary API and I am unsure if it is the best solution. > Accelerometer might be used as an input device but not always an input > device. Yeah, I see it using a joystick interface, which might be acceptable for "toy" devices like you say. But for "real" ones, we should do something else. Maybe, for devices that are going to be used by x.org, like the "toy" ones, we stick with the current input interface, but for others, we use a "real" interface, probably through hwmon, so that users can get the real data out in a consistant manner. thanks, greg k-h ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-23 0:31 ` Greg KH @ 2010-01-26 9:34 ` Dmitry Torokhov 2010-01-26 9:55 ` Hennerich, Michael 2010-01-27 7:07 ` Pavel Machek 0 siblings, 2 replies; 17+ messages in thread From: Dmitry Torokhov @ 2010-01-26 9:34 UTC (permalink / raw) To: Greg KH Cc: Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: > On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: > > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: > > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: > > > > I am not aware of these. Could you direct me to the current api? Also note that these > > > > aren't the actual alarms, merely a means of enabling the relevant event on the related > > > > event character device. > > > > > > Hm, I thought we had an accelerator interface somewhere... > > > > > > > Nope. And I am also interested in this since I am sittign on a bunch of > > accelerometers, magnetometers, etc drivers that are trying to plug into > > input sysbsystem and quite unsure what to do with them. > > > > It was OK whch HDAPS and friends when they were using input for > > secondary, toyish purposes, but these new drivers trying to use input > > devnts as primary API and I am unsure if it is the best solution. > > Accelerometer might be used as an input device but not always an input > > device. > > Yeah, I see it using a joystick interface, which might be acceptable for > "toy" devices like you say. > > But for "real" ones, we should do something else. > > Maybe, for devices that are going to be used by x.org, like the "toy" > ones, we stick with the current input interface, but for others, we use > a "real" interface, probably through hwmon, so that users can get the > real data out in a consistant manner. > I'd rather have all of them use real interface and then have a bridge to input module to enable toyish mode (unless the device in question is really truly an input device). -- Dmitry ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [RFC] Staging:IIO: New ABI 2010-01-26 9:34 ` Dmitry Torokhov @ 2010-01-26 9:55 ` Hennerich, Michael 2010-01-26 10:11 ` Dmitry Torokhov 2010-01-27 7:07 ` Pavel Machek 1 sibling, 1 reply; 17+ messages in thread From: Hennerich, Michael @ 2010-01-26 9:55 UTC (permalink / raw) To: Dmitry Torokhov, Greg KH Cc: Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > >On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: >> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: >> > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: >> > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: >> > > > I am not aware of these. Could you direct me to the current api? Also note that these >> > > > aren't the actual alarms, merely a means of enabling the relevant event on the related >> > > > event character device. >> > > >> > > Hm, I thought we had an accelerator interface somewhere... >> > > >> > >> > Nope. And I am also interested in this since I am sittign on a bunch of >> > accelerometers, magnetometers, etc drivers that are trying to plug into >> > input sysbsystem and quite unsure what to do with them. >> > >> > It was OK whch HDAPS and friends when they were using input for >> > secondary, toyish purposes, but these new drivers trying to use input >> > devnts as primary API and I am unsure if it is the best solution. >> > Accelerometer might be used as an input device but not always an input >> > device. >> >> Yeah, I see it using a joystick interface, which might be acceptable for >> "toy" devices like you say. >> >> But for "real" ones, we should do something else. >> >> Maybe, for devices that are going to be used by x.org, like the "toy" >> ones, we stick with the current input interface, but for others, we use >> a "real" interface, probably through hwmon, so that users can get the >> real data out in a consistant manner. >> > >I'd rather have all of them use real interface and then have a bridge >to input module to enable toyish mode (unless the device in question >is really truly an input device). > >-- >Dmitry I really don't see that hwmon provides facilities like input/evdev does. Queuing of events with time stamping and multiple reader support. The adxl34x accelerometer driver for example is really intended to be a input device. Send EV_KEY for x,y,z_TAP detections, send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration. With very minor platform data customization you can use this device for game controls or GUI interaction. A few examples include digital picture frames, ebook readers, etc. -Michael ------------------------------------------------------------------ ********* Analog Devices GmbH Open Platform Solutions ** ***** ** ** Wilhelm-Wagenfeld-Strasse 6 ** ***** D-80807 Munich ********* Germany Registergericht München HRB 40368, Geschäftsführer: Thomas Wessel, William A. Martin, Margaret K. Seif ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-26 9:55 ` Hennerich, Michael @ 2010-01-26 10:11 ` Dmitry Torokhov 2010-01-26 10:25 ` Hennerich, Michael 0 siblings, 1 reply; 17+ messages in thread From: Dmitry Torokhov @ 2010-01-26 10:11 UTC (permalink / raw) To: Hennerich, Michael Cc: Greg KH, Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote: > > > >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > > > >On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: > >> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: > >> > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: > >> > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: > >> > > > I am not aware of these. Could you direct me to the current api? Also note that these > >> > > > aren't the actual alarms, merely a means of enabling the relevant event on the related > >> > > > event character device. > >> > > > >> > > Hm, I thought we had an accelerator interface somewhere... > >> > > > >> > > >> > Nope. And I am also interested in this since I am sittign on a bunch of > >> > accelerometers, magnetometers, etc drivers that are trying to plug into > >> > input sysbsystem and quite unsure what to do with them. > >> > > >> > It was OK whch HDAPS and friends when they were using input for > >> > secondary, toyish purposes, but these new drivers trying to use input > >> > devnts as primary API and I am unsure if it is the best solution. > >> > Accelerometer might be used as an input device but not always an input > >> > device. > >> > >> Yeah, I see it using a joystick interface, which might be acceptable for > >> "toy" devices like you say. > >> > >> But for "real" ones, we should do something else. > >> > >> Maybe, for devices that are going to be used by x.org, like the "toy" > >> ones, we stick with the current input interface, but for others, we use > >> a "real" interface, probably through hwmon, so that users can get the > >> real data out in a consistant manner. > >> > > > >I'd rather have all of them use real interface and then have a bridge > >to input module to enable toyish mode (unless the device in question > >is really truly an input device). > > > >-- > >Dmitry > > I really don't see that hwmon provides facilities like input/evdev > does. Queuing of events with time stamping and multiple reader > support. I understand that using evdev might be very convenient but I still believe that input should be used for human interfaces, not for generic data acquisition. The idea is that userpsace consumers should be able to query device's capabilities and based on those capabilities be able to classify and properly handle the device. Now it all breaks when we get random hardware using EV_ABS/ABS_* for delivering some datastream that has nothing to do with coordinates. > The adxl34x accelerometer driver for example is really > intended to be a input device. Send EV_KEY for x,y,z_TAP detections, > send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration. > With very minor platform data customization you can use this device > for game controls or GUI interaction. A few examples include digital > picture frames, ebook readers, etc. > I see. However, can it be reasonably used for other purposes? If yes than maybe input is not the best primary subsystem the driver should belong to. Having said that I need to look at the driver again... -- Dmitry ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [RFC] Staging:IIO: New ABI 2010-01-26 10:11 ` Dmitry Torokhov @ 2010-01-26 10:25 ` Hennerich, Michael 2010-01-26 10:33 ` Manuel Stahl 2010-01-26 11:10 ` Jonathan Cameron 0 siblings, 2 replies; 17+ messages in thread From: Hennerich, Michael @ 2010-01-26 10:25 UTC (permalink / raw) To: Dmitry Torokhov Cc: Greg KH, Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote: >> >> >> >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >> > >> >On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: >> >> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: >> >> > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: >> >> > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote: >> >> > > > I am not aware of these. Could you direct me to the current api? Also note that these >> >> > > > aren't the actual alarms, merely a means of enabling the relevant event on the related >> >> > > > event character device. >> >> > > >> >> > > Hm, I thought we had an accelerator interface somewhere... >> >> > > >> >> > >> >> > Nope. And I am also interested in this since I am sittign on a bunch of >> >> > accelerometers, magnetometers, etc drivers that are trying to plug into >> >> > input sysbsystem and quite unsure what to do with them. >> >> > >> >> > It was OK whch HDAPS and friends when they were using input for >> >> > secondary, toyish purposes, but these new drivers trying to use input >> >> > devnts as primary API and I am unsure if it is the best solution. >> >> > Accelerometer might be used as an input device but not always an input >> >> > device. >> >> >> >> Yeah, I see it using a joystick interface, which might be acceptable for >> >> "toy" devices like you say. >> >> >> >> But for "real" ones, we should do something else. >> >> >> >> Maybe, for devices that are going to be used by x.org, like the "toy" >> >> ones, we stick with the current input interface, but for others, we use >> >> a "real" interface, probably through hwmon, so that users can get the >> >> real data out in a consistant manner. >> >> >> > >> >I'd rather have all of them use real interface and then have a bridge >> >to input module to enable toyish mode (unless the device in question >> >is really truly an input device). >> > >> >-- >> >Dmitry >> > >> I really don't see that hwmon provides facilities like input/evdev >> does. Queuing of events with time stamping and multiple reader >> support. > >I understand that using evdev might be very convenient but I still >believe that input should be used for human interfaces, not for generic >data acquisition. The idea is that userpsace consumers should be able to >query device's capabilities and based on those capabilities be able to >classify and properly handle the device. Now it all breaks when we get >random hardware using EV_ABS/ABS_* for delivering some datastream that >has nothing to do with coordinates. Acceleration in X,Y,Z translates pretty well in what joysticks deliver. > >> The adxl34x accelerometer driver for example is really >> intended to be a input device. Send EV_KEY for x,y,z_TAP detections, >> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration. >> With very minor platform data customization you can use this device >> for game controls or GUI interaction. A few examples include digital >> picture frames, ebook readers, etc. >> > >I see. However, can it be reasonably used for other purposes? Well - it depends. Some applications for Accelerometers also include: Personal navigation devices Hard disk drive (HDD) protection Safety I agree with you that for these three mentioned above - Input is the wrong place. >If yes >than maybe input is not the best primary subsystem the driver should >belong to. Having said that I need to look at the driver again... > >-- >Dmitry ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-26 10:25 ` Hennerich, Michael @ 2010-01-26 10:33 ` Manuel Stahl 2010-01-26 11:10 ` Jonathan Cameron 1 sibling, 0 replies; 17+ messages in thread From: Manuel Stahl @ 2010-01-26 10:33 UTC (permalink / raw) To: Hennerich, Michael Cc: Dmitry Torokhov, Greg KH, Jonathan Cameron, Jonathan Cameron, LKML, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder [-- Attachment #1.1: Type: text/plain, Size: 4235 bytes --] Am 26.01.2010 11:25, schrieb Hennerich, Michael: >> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >> On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote: >>> >>> >>>> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >>>> >>>> On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: >>>>> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: >>>>>> On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: >>>>>>> On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron > wrote: >>>>>>>> I am not aware of these. Could you direct me to the current > api? Also note that these >>>>>>>> aren't the actual alarms, merely a means of enabling the > relevant event on the related >>>>>>>> event character device. >>>>>>> >>>>>>> Hm, I thought we had an accelerator interface somewhere... >>>>>>> >>>>>> >>>>>> Nope. And I am also interested in this since I am sittign on a > bunch of >>>>>> accelerometers, magnetometers, etc drivers that are trying to > plug into >>>>>> input sysbsystem and quite unsure what to do with them. >>>>>> >>>>>> It was OK whch HDAPS and friends when they were using input for >>>>>> secondary, toyish purposes, but these new drivers trying to use > input >>>>>> devnts as primary API and I am unsure if it is the best > solution. >>>>>> Accelerometer might be used as an input device but not always an > input >>>>>> device. >>>>> >>>>> Yeah, I see it using a joystick interface, which might be > acceptable for >>>>> "toy" devices like you say. >>>>> >>>>> But for "real" ones, we should do something else. >>>>> >>>>> Maybe, for devices that are going to be used by x.org, like the > "toy" >>>>> ones, we stick with the current input interface, but for others, > we use >>>>> a "real" interface, probably through hwmon, so that users can get > the >>>>> real data out in a consistant manner. >>>>> >>>> >>>> I'd rather have all of them use real interface and then have a > bridge >>>> to input module to enable toyish mode (unless the device in question >>>> is really truly an input device). >>>> >>>> -- >>>> Dmitry >>> >> >>> I really don't see that hwmon provides facilities like input/evdev >>> does. Queuing of events with time stamping and multiple reader >>> support. >> >> I understand that using evdev might be very convenient but I still >> believe that input should be used for human interfaces, not for generic >> data acquisition. The idea is that userpsace consumers should be able > to >> query device's capabilities and based on those capabilities be able to >> classify and properly handle the device. Now it all breaks when we get >> random hardware using EV_ABS/ABS_* for delivering some datastream that >> has nothing to do with coordinates. > > Acceleration in X,Y,Z translates pretty well in what joysticks deliver. But it's not only about accelerometers here. We also have gyros, magnetometers, pressure sensors and generic ADCs. >>> The adxl34x accelerometer driver for example is really >>> intended to be a input device. Send EV_KEY for x,y,z_TAP detections, >>> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration. >>> With very minor platform data customization you can use this device >>> for game controls or GUI interaction. A few examples include digital >>> picture frames, ebook readers, etc. >>> >> >> I see. However, can it be reasonably used for other purposes? > > Well - it depends. Some applications for Accelerometers also include: > Personal navigation devices (low to mid data rate) > Hard disk drive (HDD) protection (only alerts) > Safety (probably low data rate) What we want with IIO is a common high performance interface to these devices. That's why we have ring buffers in the kernel. Possible applications are robotics, precise navigation, data aquisition, etc. Regards, -- Dipl.-Inf. Manuel Stahl Fraunhofer-Institut für Integrierte Schaltungen IIS - Leistungsoptimierte Systeme - Nordostpark 93 Telefon +49 (0)911/58061-6419 90411 Nürnberg Fax +49 (0)911/58061-6398 http://www.iis.fraunhofer.de manuel.stahl@iis.fraunhofer.de [-- Attachment #1.2: manuel_stahl.vcf --] [-- Type: text/x-vcard, Size: 170 bytes --] begin:vcard fn:Manuel Stahl n:Stahl;Manuel email;internet:manuel.stahl@iis.fraunhofer.de tel;work:+49 911 58061-6419 x-mozilla-html:FALSE version:2.1 end:vcard [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 6148 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-26 10:25 ` Hennerich, Michael 2010-01-26 10:33 ` Manuel Stahl @ 2010-01-26 11:10 ` Jonathan Cameron 1 sibling, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2010-01-26 11:10 UTC (permalink / raw) To: Hennerich, Michael Cc: Dmitry Torokhov, Greg KH, Jonathan Cameron, LKML, Manuel Stahl, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder On 01/26/10 10:25, Hennerich, Michael wrote: >> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >> On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote: >>> >>> >>>> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >>>> >>>> On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote: >>>>> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote: >>>>>> On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote: >>>>>>> On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron > wrote: >>>>>>>> I am not aware of these. Could you direct me to the current > api? Also note that these >>>>>>>> aren't the actual alarms, merely a means of enabling the > relevant event on the related >>>>>>>> event character device. >>>>>>> >>>>>>> Hm, I thought we had an accelerator interface somewhere... >>>>>>> >>>>>> >>>>>> Nope. And I am also interested in this since I am sittign on a > bunch of >>>>>> accelerometers, magnetometers, etc drivers that are trying to > plug into >>>>>> input sysbsystem and quite unsure what to do with them. >>>>>> >>>>>> It was OK whch HDAPS and friends when they were using input for >>>>>> secondary, toyish purposes, but these new drivers trying to use > input >>>>>> devnts as primary API and I am unsure if it is the best > solution. >>>>>> Accelerometer might be used as an input device but not always an > input >>>>>> device. >>>>> >>>>> Yeah, I see it using a joystick interface, which might be > acceptable for >>>>> "toy" devices like you say. >>>>> >>>>> But for "real" ones, we should do something else. >>>>> >>>>> Maybe, for devices that are going to be used by x.org, like the > "toy" >>>>> ones, we stick with the current input interface, but for others, > we use >>>>> a "real" interface, probably through hwmon, so that users can get > the >>>>> real data out in a consistant manner. >>>>> >>>> >>>> I'd rather have all of them use real interface and then have a > bridge >>>> to input module to enable toyish mode (unless the device in question >>>> is really truly an input device). >>>> >>>> -- >>>> Dmitry >>> >> >>> I really don't see that hwmon provides facilities like input/evdev >>> does. Queuing of events with time stamping and multiple reader >>> support. >> >> I understand that using evdev might be very convenient but I still >> believe that input should be used for human interfaces, not for generic >> data acquisition. The idea is that userpsace consumers should be able > to >> query device's capabilities and based on those capabilities be able to >> classify and properly handle the device. Now it all breaks when we get >> random hardware using EV_ABS/ABS_* for delivering some datastream that >> has nothing to do with coordinates. > > Acceleration in X,Y,Z translates pretty well in what joysticks deliver. > >> >>> The adxl34x accelerometer driver for example is really >>> intended to be a input device. Send EV_KEY for x,y,z_TAP detections, >>> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration. >>> With very minor platform data customization you can use this device >>> for game controls or GUI interaction. A few examples include digital >>> picture frames, ebook readers, etc. >>> >> >> I see. However, can it be reasonably used for other purposes? > > Well - it depends. Some applications for Accelerometers also include: > Personal navigation devices > Hard disk drive (HDD) protection > Safety Just to add the apps I tend see these in (including that particular chip). Sports performance monitoring (including live feedback and logging situations), equine gait and I know at least one group who use these cheap 'input' sensors for UAV navigation and packages instrumenting birds in flight (not sure exactly which chip they are using right now but I know they were trying to obtain samples of the adxl345 a while back.) Obviously not all of the above are under Linux, but given the ease of development and increasingly good low power and crucially small embedded boards it is becoming more common. Round here the smallest end is still bare metal code, but a lot of the initial prototypes are Linux based. Jonathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-26 9:34 ` Dmitry Torokhov 2010-01-26 9:55 ` Hennerich, Michael @ 2010-01-27 7:07 ` Pavel Machek 1 sibling, 0 replies; 17+ messages in thread From: Pavel Machek @ 2010-01-27 7:07 UTC (permalink / raw) To: Dmitry Torokhov Cc: Greg KH, Jonathan Cameron, Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder > > > Nope. And I am also interested in this since I am sittign on a bunch of > > > accelerometers, magnetometers, etc drivers that are trying to plug into > > > input sysbsystem and quite unsure what to do with them. > > > > > > It was OK whch HDAPS and friends when they were using input for > > > secondary, toyish purposes, but these new drivers trying to use input > > > devnts as primary API and I am unsure if it is the best solution. > > > Accelerometer might be used as an input device but not always an input > > > device. > > > > Yeah, I see it using a joystick interface, which might be acceptable for > > "toy" devices like you say. > > > > But for "real" ones, we should do something else. > > > > Maybe, for devices that are going to be used by x.org, like the "toy" > > ones, we stick with the current input interface, but for others, we use > > a "real" interface, probably through hwmon, so that users can get the > > real data out in a consistant manner. > > I'd rather have all of them use real interface and then have a bridge > to input module to enable toyish mode (unless the device in question > is really truly an input device). Well, if you look at the PDA class devices, they really use magnetometers and accelerometers for input. I guess we should look at better support in input... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] Staging:IIO: New ABI 2010-01-22 20:47 ` Greg KH 2010-01-23 0:14 ` Dmitry Torokhov @ 2010-01-24 11:27 ` Jonathan Cameron 1 sibling, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2010-01-24 11:27 UTC (permalink / raw) To: Greg KH Cc: Jonathan Cameron, LKML, Manuel Stahl, Hennerich, Michael, Frysinger, Michael, Getz, Robin, Jean Delvare, Trisal, Kalhan, Zhang, Xing Z, Ira Snyder Hi Greg, >>> On Wed, Jan 20, 2010 at 03:13:40PM +0000, Jonathan Cameron wrote: >>>> What: /sys/class/iio/device[n] >>>> Description: >>>> Hardware chip or device accessed by on communication port. >>>> Corresponds to a grouping of sensor channels. >>>> >>>> What: /sys/class/iio/trigger[n] >>>> Description: >>>> An event driven driver of data capture to an in kernel buffer. >>>> May be provided a device driver that also has an IIO device >>>> based on hardware generated events (e.g. data ready) or >>>> provided by other hardware (e.g. periodic timer or gpio) >>>> Contains trigger type specific elements. These do not >>>> generalize well. >>>> >>>> >>>> What: /sys/class/iio/ring_buffer[m] >>>> Description: >>>> Link to /sys/class/iio/device[n]/ring_buffer[m]. Ring buffer >>>> numbering may not match that of device as some devices do not >>>> have ring buffers. >>> >>> Why is this link needed? Why can't you just look in the device >>> directory for a ring buffer? And wouldn't the ring buffer be 1..n for >>> every device? They shouldn't be "unique" for all iio devices, that >>> would be wierd. >> I'm a little unclear what you mean here (so my apologies if I'm misinterpreting!) >> A given IIO device will indeed have a either none or typically 1 ring buffers. >> They are not currently shared across devices. Aggregation if desired is done >> in userspace. > > Ok, that's fine, but the name of those buffers do not have to be unique > to all ring buffers in the system. > > Hm, oh yeah, they do, ok, nevermind, stupid me :) > >>>> What: /sys/class/iio/device[n]/name >>>> Description: >>>> Description of the physical chip / device. Typically a part >>>> number. >>>> >>>> What: /sys/class/iio/device[n]/volt_[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). >>> >>> So what would 'name' be? >> This is for a few device corner cases such as volt_supply_raw for the the >> adis16350 below. It can't really be used as a general purpose ADC >> so the idea was to separate it out. The vast majority of voltage channels >> would simply be numbered. There is an argument that, it might make sense >> to support this single parameter via hwmon, but then there are high end >> gyros where we would be grabbing the voltage, temperature and actual reading >> on each trigger so as to be able to compensate for the huge difference >> these can make to the resulting data. > > But again, what would 'name' be? Probably an option from a small list. (supply being the only element right now!) Actually, whilst the list is small we might as well put it straight in the abi description line. > >>>> What: /sys/class/iio/device[n]/volt_[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 volts. If shared across all voltage channels the m is not present. >>> >>> For all of these voltage measurements, why use something different from >>> what the kernel already supports for the existing hardware monitoring >>> devices? There is already a well-defined api for these things. >> Agreed. We did consider using in0 etc as per hwmon but decided that we were >> breaking sufficiently from the approach there (where the readings are always >> provided in microvolts iirc) that we could change the name to something that >> was a little more specific. I'm not overly tied to volt but the semantics >> are different enough here (with offsets and gain passed to userspace) that >> we may actually create confusion by mirroring that api. > > I really think you should merge with that api somehow. > > I understand that you don't want to do conversions in the kernel, so > perhaps there could be some way to show this like you have described, > that the hwmon interface could also use. > > That way userspace tools will work for all types of devices, and you > don't have a custom interface just for these device. Unification is a > good thing :) A good point. I'll have a think about how to do this then post an update including the hwmon list to see if we can work out what needs adding to their current interface. > >>>> What: /sys/class/iio/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 volt[m]. >>>> Units after application of scale and offset are m/s^2. >>> >>> Shouldn't this just use the existing input accelerometer interface so as >>> to keep userspace sane? >> Again, it comes down to whether we process the data or not. IIO is all about >> the ability to handle things fast. These sysfs interfaces are actually meant >> to mirror the chrdev ring buffer accesses which are the primary access point >> for higher end devices. A lot of the use cases are either interested in logging >> for later use, or algorithms that will run in the device units (sometime in integer >> arithmetic). Hence all conversion to sane units is left to userspace. The >> drivers merely provide sufficient information to do this conversion if it >> is desired. > > See above. I suggest working with the hwmon developers to add the "raw" > type interface to their api making these able to be used there as well. > >>>> What: /sys/class/iio/device[n]/event_line[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/class/iio/device[n]/event_line[m]/dev >>>> Description: >>>> major:minor character device numbers. >>> >>> No, don't bury devices down a level in sysfs, that's not ok. Actually, >>> I think it would take you a lot of work to get this to properly work on >>> the implementation side :) >> This bit of the documentation is indeed wrong (oops). These are members of the IIO >> class and so this is just a link (much like the event elements in input) created >> by making them in class iio with the device as a a parent. Again, application >> wise we aren't normally interested in aggregation so there is one (or more) of these >> per device. > > Ok. > >>> >>> If event_lines need device nodes, then they should be real devices. >> (oops) The are ;) > > Heh, that will not work, as Kay described :) > >>> Actually, all of this looks like it needs to be a bus, not a class, if >>> you are having this many different types of things hanging off of them. >>> Have you thought about that instead? It would make your code a lot >>> easier in the end. >> That is definitely an option. The reason we didn't is more to do with following >> the most similar current case (input) than any particular preference. > > As Kay said, this should be a bus, and you should have devices attach to > them, be it virtual or not. Or, you just tie into the hwmon interface > which makes it much easier for you overall. We'll definitely move over to a bus. I'd fallen for the naming and never really considered it as an option! As for tying into hwmon, I'll take another look as I can see it may be simpler with the bus structure separating the different 'devices'. > >>>> Again taking accel_x0 as example and serious liberties with ABI spec. >>>> >>>> What: /sys/.../event_line[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/.../event_line[m]/accel_x0_roc[_high|_low] >>>> Description: >>>> Same as above but based on the first differential of the value. >>>> >>>> >>>> What: /sys/.../event_line[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/.../event_line[m]/accel_x0[_thresh|_roc][_high|_low]_value >>>> Description: >>>> The actual value of the threshold either in raw device units >>>> obtained by reverse application of scale and offfset to the >>>> acceleration in m/s^2. >>> >>> Again, look at our existing apis, I think we already cover these types >>> of things, don't create new ones please. >> I am not aware of these. Could you direct me to the current api? Also note that these >> aren't the actual alarms, merely a means of enabling the relevant event on the related >> event character device. > > Hm, I thought we had an accelerator interface somewhere... (cleared up by Dmitry further down the thread) > >>>> What: /sys/.../event_line[m]/free_fall >>>> Description: >>>> Common hardware event in accelerometers. Takes no parameters. >>> >>> I know we have this one already, please use it. >> >> Again, does it make sense to match api when the result is very different? The event >> infrastructure in IIO is much slimmer than that in input (this was one of the original >> reasons for not simply adding these things to input in the first place). This particular >> example is a bit unusual in that the current api (hwmon/lis3lv02d.c for example) handles >> this via a dedicated freefall character device. This doesn't really generalize to the more >> complex events handled here. To be honest this one doesn't really make sense in IIO's >> intended applications so it might be best to drop it entirely! > > Yeah, a dedicated char device doesn't seem to make much sense either, > but any unification you could find here would be nice. Even if it means > the existing driver converts over to your new api :) Fair point. > >>> Again, don't bury devices. Or if you are, use a bus, not a class, >>> that's the wrong classification. >> Cool, I'll look into making the change. What we really have here >> is a single conceptual device using a pair or character interfaces. Is a bus >> the right way to handle that? >> >> How about the following under a bus (this is for a single physical chip). >> >> device0 >> event0 (for physical events) >> ringaccess0 (actual device from which data is read) >> ringevent0 (associated event interface for the ring - ideally not aggregated with the event0) >> >> and sometimes: >> trigger0 >> >> Is that best way to go. Currently ringacces0 and ring event0 are >> grouped under ring_buffer0 but that was simply for the reason they are >> always matched. > > Yes, that would work, and make sense. Excellent, Thanks for taking a look at this! Jonathan ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-01-27 7:08 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-01-20 15:13 [RFC] Staging:IIO: New ABI Jonathan Cameron 2010-01-20 15:37 ` Greg KH 2010-01-20 16:40 ` Kay Sievers 2010-01-20 16:53 ` Jonathan Cameron 2010-01-20 17:14 ` Kay Sievers 2010-01-25 18:52 ` Jonathan Cameron 2010-01-22 20:47 ` Greg KH 2010-01-23 0:14 ` Dmitry Torokhov 2010-01-23 0:31 ` Greg KH 2010-01-26 9:34 ` Dmitry Torokhov 2010-01-26 9:55 ` Hennerich, Michael 2010-01-26 10:11 ` Dmitry Torokhov 2010-01-26 10:25 ` Hennerich, Michael 2010-01-26 10:33 ` Manuel Stahl 2010-01-26 11:10 ` Jonathan Cameron 2010-01-27 7:07 ` Pavel Machek 2010-01-24 11:27 ` Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.