On 10/18/10 14:49, Jonathan Cameron wrote: > Hi all, I've pasted the following in directly as diffs of these files are somewhat > hard to comment on and it's more or less rewritten. > > The basic principal here was to move towards cleanly documenting every > attribute we have. This involved firstly moving to X Y Z for numeric > indexing and adding multiple What: lines to the file to list everything. > Basically we want people to be able to grep when they come across an > attribute and wonder what it does. There are a few omissions in here > at the moment (rot, angl, hyst) but those are mainly because I'm not quite > sure what they are and haven't datasheet dived as yet. I have also cut > out a few things that we agreed interfaces for but which are not currently > used by any drivers (meanperiod for example) > > A couple of our drivers aren't currently compliant with this spec > (including some of mine ;) The other addition that will come is that > of inY_thresh_above_en and inY_thresh_below_en. This was suggested > in a sensor outside iio that is matching our abi (more or less) > and seems a sensible and clear way of handling 'level' type interrupts > (that is those that will retrigger if the interrupt is cleared and they > are still true). > > All comments welcome! Lets get this nice and clean once and for all. > I haven't rolled in the light sensor attributes as yet, but will look > at how simple that is after we have the current content cleaned up. As this has been on the list with no comments for a month, I've take an executive decision and sent it on to Greg KH. It may be far from perfect, but I think it's a considerable improvement on the previous version. Mainly I want this in place so I can start shouting at people for undocumented attributes in all the new drivers :) Note that such docs will become obligatory before I ack patches, that add new general attributes, sometime in the near future, I really don't want our documentation to slip as it just makes the review process steadily harder! Jonathan > ... > > What: /sys/bus/iio/devices/deviceX > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Hardware chip or device accessed by on communication port. > Corresponds to a grouping of sensor channels. X is the IIO > index of the device. > > What: /sys/bus/iio/devices/triggerX > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > An event driven driver of data capture to an in kernel buffer. > May be provided by a device driver that also has an IIO device > based on hardware generated events (e.g. data ready) or > provided by a separate driver for other hardware (e.g. > periodic timer, gpio or high resolution timer). > Contains trigger type specific elements. These do not > generalize well and hence are not documented in this file. > X is the IIO index of the trigger. > > What: /sys/bus/iio/devices/deviceX:buffer > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Link to /sys/class/iio/deviceX/deviceX:buffer. X indicates > the device with which this buffer buffer is associated. > > What: /sys/bus/iio/devices/deviceX/name > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Description of the physical chip / device for device X. > Typically a part number. > > What: /sys/bus/iio/devices/deviceX/sampling_frequency > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Some devices have internal clocks. This parameter sets the > resulting sampling frequency. In many devices this > parameter has an effect on input filters etc rather than > simply controlling when the input is sampled. As this > effects datardy triggers, hardware buffers and the sysfs > direct access interfaces, it may be found in any of the > relevant directories. If it effects all of the above > then it is to be found in the base device directory as here. > > What: /sys/bus/iio/devices/deviceX/sampling_frequency_available > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > When the internal sampling clock can only take a small > discrete set of values, this file lists those available. > > What: /sys/bus/iio/devices/deviceX/inY_raw > What: /sys/bus/iio/devices/deviceX/inY_supply_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Raw (unscaled no bias removal etc) voltage measurement from > channel Y. In special cases where the channel does not > correspond to externally available input one of the named > versions may be used. The number must always be specified and > unique to allow association with event codes. > > What: /sys/bus/iio/devices/deviceX/inY-inZ_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Raw (unscaled) differential voltage measurement equivalent to > channel Y - channel Z where these channel numbers apply to the > physically equivalent inputs when non differential readings are > separately available. In differential only parts, then all that > is required is a consistent labeling. > > What: /sys/bus/iio/devices/deviceX/temp_raw > What: /sys/bus/iio/devices/deviceX/temp_x_raw > What: /sys/bus/iio/devices/deviceX/temp_y_raw > What: /sys/bus/iio/devices/deviceX/temp_z_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Raw (unscaled no bias removal etc) temperature measurement. > It an axis is specified it generally means that the temperature > sensor is associated with one part of a compound device (e.g. > a gyroscope axis). > > What: /sys/bus/iio/devices/deviceX/accel_x_raw > What: /sys/bus/iio/devices/deviceX/accel_y_raw > What: /sys/bus/iio/devices/deviceX/accel_z_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > 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 > inY. Units after application of scale and offset are m/s^2. > > What: /sys/bus/iio/devices/deviceX/gyro_x_raw > What: /sys/bus/iio/devices/deviceX/gyro_y_raw > What: /sys/bus/iio/devices/deviceX/gyro_z_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Angular velocity about axis x, y or z (may be arbitrarily > assigned) Data converted by application of offset then scale to > radians per second. Has all the equivalent parameters as > per inY. > > What: /sys/bus/iio/devices/deviceX/incli_x_raw > What: /sys/bus/iio/devices/deviceX/incli_y_raw > What: /sys/bus/iio/devices/deviceX/incli_z_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Inclination raw reading about axis x, y or z (may be > arbitrarily assigned). Data converted by application of offset > and scale to Degrees. > > What: /sys/bus/iio/devices/deviceX/magn_x_raw > What: /sys/bus/iio/devices/deviceX/magn_y_raw > What: /sys/bus/iio/devices/deviceX/magn_z_raw > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > 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 inY. > > What: /sys/bus/iio/devices/deviceX/accel_x_peak_raw > What: /sys/bus/iio/devices/deviceX/accel_y_peak_raw > What: /sys/bus/iio/devices/deviceX/accel_z_peak_raw > KernelVersion: 2.6.36 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Some devices provide a store of the highest value seen since > some reset condition. These attributes allow access to this > and are otherwise the direct equivalent of the > <type>Y[_name]_raw attributes. > > What: /sys/bus/iio/devices/deviceX/accel_xyz_squared_peak_raw > KernelVersion: 2.6.36 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > A computed peak value based on the sum squared magnitude of > the underlying value in the specified directions. > > What: /sys/bus/iio/devices/deviceX/accel_offset > What: /sys/bus/iio/devices/deviceX/temp_offset > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > If known for a device, offset to be added to <type>[Y]_raw prior > to scaling by <type>[Y]_scale in order to obtain value in the > <type> units as specified in <type>[y]_raw documentation. > Not present if the offset is always 0 or unknown. If Y is not > present, then the offset applies to all in channels of <type>. > May be writable if a variable offset can be applied on the > device. Note that this is different to calibbias which > is for devices (or drivers) that apply offsets to compensate > for variation between different instances of the part, typically > adjusted by using some hardware supported calibration procedure. > > What: /sys/bus/iio/devices/deviceX/inY_scale > What: /sys/bus/iio/devices/deviceX/inY_supply_scale > What: /sys/bus/iio/devices/deviceX/in_scale > What: /sys/bus/iio/devices/deviceX/accel_scale > What: /sys/bus/iio/devices/deviceX/accel_peak_scale > What: /sys/bus/iio/devices/deviceX/gyro_scale > What: /sys/bus/iio/devices/deviceX/magn_scale > What: /sys/bus/iio/devices/deviceX/magn_x_scale > What: /sys/bus/iio/devices/deviceX/magn_y_scale > What: /sys/bus/iio/devices/deviceX/magn_z_scale > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > If known for a device, scale to be applied to <type>Y[_name]_raw > post addition of <type>[Y][_name]_offset in order to obtain the > measured value in <type> units as specified in > <type>[Y][_name]_raw documentation.. If shared across all in > channels then Y is not present and the value is called > <type>[Y][_name]_scale. The peak modifier means this value > is applied to <type>Y[_name]_peak_raw values. > > What: /sys/bus/iio/devices/deviceX/accel_x_calibbias > What: /sys/bus/iio/devices/deviceX/accel_y_calibbias > What: /sys/bus/iio/devices/deviceX/accel_z_calibbias > What: /sys/bus/iio/devices/deviceX/gyro_x_calibbias > What: /sys/bus/iio/devices/deviceX/gyro_y_calibbias > What: /sys/bus/iio/devices/deviceX/gyro_z_calibbias > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Hardware applied calibration offset. (assumed to fix production > inaccuracies). If shared across all channels, <type>_calibbias > is used. > > What /sys/bus/iio/devices/deviceX/inY_calibscale > What /sys/bus/iio/devices/deviceX/inY_supply_calibscale > What /sys/bus/iio/devices/deviceX/in_calibscale > What /sys/bus/iio/devices/deviceX/accel_x_calibscale > What /sys/bus/iio/devices/deviceX/accel_y_calibscale > What /sys/bus/iio/devices/deviceX/accel_z_calibscale > What /sys/bus/iio/devices/deviceX/gyro_x_calibscale > What /sys/bus/iio/devices/deviceX/gyro_y_calibscale > What /sys/bus/iio/devices/deviceX/gyro_z_calibscale > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Hardware applied calibration scale factor. (assumed to fix > production inaccuracies). If shared across all channels, > <type>_calibscale is used. > > What: /sys/bus/iio/devices/deviceX/accel_scale_available > KernelVersion: 2.635 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > If a discrete set of scale values are available, they > are listed in this attribute. > > What: /sys/bus/iio/devices/deviceX/deviceX:eventY > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Configuration of which hardware generated events are passed up > to user-space. > > What: /sys/bus/iio/devices/deviceX:event/dev > What: /sys/bus/iio/devices/deviceX:eventY/dev > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > major:minor character device numbers for the event line Y of > device X. > > What: /sys/.../deviceX:eventY/accel_x_thresh_rising_en > What: /sys/.../deviceX:eventY/accel_x_thresh_falling_en > What: /sys/.../deviceX:eventY/accel_y_thresh_rising_en > What: /sys/.../deviceX:eventY/accel_y_thresh_falling_en > What: /sys/.../deviceX:eventY/accel_z_thresh_rising_en > What: /sys/.../deviceX:eventY/accel_z_thresh_falling_en > What: /sys/.../deviceX:eventY/gyro_x_thresh_rising_en > What: /sys/.../deviceX:eventY/gyro_x_thresh_falling_en > What: /sys/.../deviceX:eventY/gyro_y_thresh_rising_en > What: /sys/.../deviceX:eventY/gyro_y_thresh_falling_en > What: /sys/.../deviceX:eventY/gyro_z_thresh_rising_en > What: /sys/.../deviceX:eventY/gyro_z_thresh_falling_en > What: /sys/.../deviceX:eventY/magn_x_thresh_rising_en > What: /sys/.../deviceX:eventY/magn_x_thresh_falling_en > What: /sys/.../deviceX:eventY/magn_y_thresh_rising_en > What: /sys/.../deviceX:eventY/magn_y_thresh_falling_en > What: /sys/.../deviceX:eventY/magn_z_thresh_rising_en > What: /sys/.../deviceX:eventY/magn_z_thresh_falling_en > What: /sys/.../deviceX:eventY/inZ_supply_thresh_rising_en > What: /sys/.../deviceX:eventY/inZ_supply_thresh_falling_en > What: /sys/.../deviceX:eventY/inZ_thresh_rising_en > What: /sys/.../deviceX:eventY/inZ_thresh_falling_en > What: /sys/.../deviceX:eventY/temp_thresh_rising_en > What: /sys/.../deviceX:eventY/temp_thresh_falling_en > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Event generated when channel passes a threshold in the specified > (_rising|_falling) direction. If the direction is not specified, > then either the device will report an event which ever direction > a single threshold value is called in (e.g. > <type>[Z][_name]_<raw|input>_thresh_value) or > <type>[Z][_name]_<raw|input>_thresh_rising_value and > <type>[Z][_name]_<raw|input>_thresh_falling_value may take > different values, but the device can only enable both thresholds > or neither. > Note the driver will assume the last p events requested are > to be enabled where p is however many it supports (which may > vary depending on the exact set requested. So if you want to be > sure you have set what you think you have, check the contents of > these attributes after everything is configured. 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 event was previously enabled). > > What: /sys/.../deviceX:eventY/accel_x_roc_rising_en > What: /sys/.../deviceX:eventY/accel_x_roc_falling_en > What: /sys/.../deviceX:eventY/accel_y_roc_rising_en > What: /sys/.../deviceX:eventY/accel_y_roc_falling_en > What: /sys/.../deviceX:eventY/accel_z_roc_rising_en > What: /sys/.../deviceX:eventY/accel_z_roc_falling_en > What: /sys/.../deviceX:eventY/gyro_x_roc_rising_en > What: /sys/.../deviceX:eventY/gyro_x_roc_falling_en > What: /sys/.../deviceX:eventY/gyro_y_roc_rising_en > What: /sys/.../deviceX:eventY/gyro_y_roc_falling_en > What: /sys/.../deviceX:eventY/gyro_z_roc_rising_en > What: /sys/.../deviceX:eventY/gyro_z_roc_falling_en > What: /sys/.../deviceX:eventY/magn_x_roc_rising_en > What: /sys/.../deviceX:eventY/magn_x_roc_falling_en > What: /sys/.../deviceX:eventY/magn_y_roc_rising_en > What: /sys/.../deviceX:eventY/magn_y_roc_falling_en > What: /sys/.../deviceX:eventY/magn_z_roc_rising_en > What: /sys/.../deviceX:eventY/magn_z_roc_falling_en > What: /sys/.../deviceX:eventY/inZ_supply_roc_rising_en > What: /sys/.../deviceX:eventY/inZ_supply_roc_falling_en > What: /sys/.../deviceX:eventY/inZ_roc_rising_en > What: /sys/.../deviceX:eventY/inZ_roc_falling_en > What: /sys/.../deviceX:eventY/temp_roc_rising_en > What: /sys/.../deviceX:eventY/temp_roc_falling_en > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Event generated when channel passes a threshold on the rate of > change (1st differential) in the specified (_rising|_falling) > direction. If the direction is not specified, then either the > device will report an event which ever direction a single > threshold value is called in (e.g. > <type>[Z][_name]_<raw|input>_roc_value) or > <type>[Z][_name]_<raw|input>_roc_rising_value and > <type>[Z][_name]_<raw|input>_roc_falling_value may take > different values, but the device can only enable both rate of > change thresholds or neither. > Note the driver will assume the last p events requested are > to be enabled where p is however many it supports (which may > vary depending on the exact set requested. So if you want to be > sure you have set what you think you have, check the contents of > these attributes after everything is configured. 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 event was previously enabled). > > What: /sys/.../deviceX:eventY/accel_x_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/accel_x_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/accel_y_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/accel_y_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/accel_z_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/accel_z_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/gyro_x_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/gyro_x_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/gyro_y_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/gyro_y_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/gyro_z_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/gyro_z_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/magn_x_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/magn_x_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/magn_y_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/magn_y_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/magn_z_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/magn_z_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/inZ_supply_raw_thresh_rising_value > What: /sys/.../deviceX:eventY/inZ_supply_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/inZ_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/inZ_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/temp_raw_thresh_falling_value > What: /sys/.../deviceX:eventY/temp_raw_thresh_falling_value > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Specifies the value of threshold that the device is comparing > against for the events enabled by > <type>Z[_name]_thresh[_rising|falling]_en. > If separate attributes exist for the two directions, but > direction is not specified for this attribute, then a single > threshold value applies to both directions. > The raw or input element of the name indicates whether the > value is in raw device units or in processed units (as _raw > and _input do on sysfs direct channel read attributes). > > What: /sys/.../deviceX:eventY/accel_x_raw_roc_rising_value > What: /sys/.../deviceX:eventY/accel_x_raw_roc_falling_value > What: /sys/.../deviceX:eventY/accel_y_raw_roc_rising_value > What: /sys/.../deviceX:eventY/accel_y_raw_roc_falling_value > What: /sys/.../deviceX:eventY/accel_z_raw_roc_rising_value > What: /sys/.../deviceX:eventY/accel_z_raw_roc_falling_value > What: /sys/.../deviceX:eventY/gyro_x_raw_roc_rising_value > What: /sys/.../deviceX:eventY/gyro_x_raw_roc_falling_value > What: /sys/.../deviceX:eventY/gyro_y_raw_roc_rising_value > What: /sys/.../deviceX:eventY/gyro_y_raw_roc_falling_value > What: /sys/.../deviceX:eventY/gyro_z_raw_roc_rising_value > What: /sys/.../deviceX:eventY/gyro_z_raw_roc_falling_value > What: /sys/.../deviceX:eventY/magn_x_raw_roc_rising_value > What: /sys/.../deviceX:eventY/magn_x_raw_roc_falling_value > What: /sys/.../deviceX:eventY/magn_y_raw_roc_rising_value > What: /sys/.../deviceX:eventY/magn_y_raw_roc_falling_value > What: /sys/.../deviceX:eventY/magn_z_raw_roc_rising_value > What: /sys/.../deviceX:eventY/magn_z_raw_roc_falling_value > What: /sys/.../deviceX:eventY/inZ_supply_raw_roc_rising_value > What: /sys/.../deviceX:eventY/inZ_supply_raw_roc_falling_value > What: /sys/.../deviceX:eventY/inZ_raw_roc_falling_value > What: /sys/.../deviceX:eventY/inZ_raw_roc_falling_value > What: /sys/.../deviceX:eventY/temp_raw_roc_falling_value > What: /sys/.../deviceX:eventY/temp_raw_roc_falling_value > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Specifies the value of rate of change threshold that the > device is comparing against for the events enabled by > <type>[Z][_name]_roc[_rising|falling]_en. > If separate attributes exist for the two directions, > but direction is not specified for this attribute, > then a single threshold value applies to both directions. > The raw or input element of the name indicates whether the > value is in raw device units or in processed units (as _raw > and _input do on sysfs direct channel read attributes). > > What: /sys/.../deviceX:eventY/accel_x_thresh_rising_period > What: /sys/.../deviceX:eventY/accel_x_thresh_falling_period > hat: /sys/.../deviceX:eventY/accel_x_roc_rising_period > What: /sys/.../deviceX:eventY/accel_x_roc_falling_period > What: /sys/.../deviceX:eventY/accel_y_thresh_rising_period > What: /sys/.../deviceX:eventY/accel_y_thresh_falling_period > What: /sys/.../deviceX:eventY/accel_y_roc_rising_period > What: /sys/.../deviceX:eventY/accel_y_roc_falling_period > What: /sys/.../deviceX:eventY/accel_z_thresh_rising_period > What: /sys/.../deviceX:eventY/accel_z_thresh_falling_period > What: /sys/.../deviceX:eventY/accel_z_roc_rising_period > What: /sys/.../deviceX:eventY/accel_z_roc_falling_period > What: /sys/.../deviceX:eventY/gyro_x_thresh_rising_period > What: /sys/.../deviceX:eventY/gyro_x_thresh_falling_period > What: /sys/.../deviceX:eventY/gyro_x_roc_rising_period > What: /sys/.../deviceX:eventY/gyro_x_roc_falling_period > What: /sys/.../deviceX:eventY/gyro_y_thresh_rising_period > What: /sys/.../deviceX:eventY/gyro_y_thresh_falling_period > What: /sys/.../deviceX:eventY/gyro_y_roc_rising_period > What: /sys/.../deviceX:eventY/gyro_y_roc_falling_period > What: /sys/.../deviceX:eventY/gyro_z_thresh_rising_period > What: /sys/.../deviceX:eventY/gyro_z_thresh_falling_period > What: /sys/.../deviceX:eventY/gyro_z_roc_rising_period > What: /sys/.../deviceX:eventY/gyro_z_roc_falling_period > What: /sys/.../deviceX:eventY/magn_x_thresh_rising_period > What: /sys/.../deviceX:eventY/magn_x_thresh_falling_period > What: /sys/.../deviceX:eventY/magn_x_roc_rising_period > What: /sys/.../deviceX:eventY/magn_x_roc_falling_period > What: /sys/.../deviceX:eventY/magn_y_thresh_rising_period > What: /sys/.../deviceX:eventY/magn_y_thresh_falling_period > What: /sys/.../deviceX:eventY/magn_y_roc_rising_period > What: /sys/.../deviceX:eventY/magn_y_roc_falling_period > What: /sys/.../deviceX:eventY/magn_z_thresh_rising_period > What: /sys/.../deviceX:eventY/magn_z_thresh_falling_period > What: /sys/.../deviceX:eventY/magn_z_roc_rising_period > What: /sys/.../deviceX:eventY/magn_z_roc_falling_period > What: /sys/.../deviceX:eventY/inZ_supply_thresh_rising_period > What: /sys/.../deviceX:eventY/inZ_supply_thresh_falling_period > What: /sys/.../deviceX:eventY/inz_supply_roc_rising_period > What: /sys/.../deviceX:eventY/inZ_supply_roc_falling_period > What: /sys/.../deviceX:eventY/inZ_thresh_rising_period > What: /sys/.../deviceX:eventY/inZ_thresh_falling_period > What: /sys/.../deviceX:eventY/inZ_roc_rising_period > What: /sys/.../deviceX:eventY/inZ_roc_falling_period > What: /sys/.../deviceX:eventY/temp_thresh_rising_period > What: /sys/.../deviceX:eventY/temp_thresh_falling_period > What: /sys/.../deviceX:eventY/temp_roc_rising_period > What: /sys/.../deviceX:eventY/temp_roc_falling_period > What: /sys/.../deviceX:eventY/accel_x&y&z_mag_falling_period > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Period of time (in seconds) for which the condition must be > met before an event is generated. If direction is not > specified then this period applies to both directions. > > What: /sys/.../deviceX:eventY/accel_mag_en > What: /sys/.../deviceX:eventY/accel_mag_rising_en > What: /sys/.../deviceX:eventY/accel_mag_falling_en > What: /sys/.../deviceX:eventY/accel_x_mag_en > What: /sys/.../deviceX:eventY/accel_x_mag_rising_en > What: /sys/.../deviceX:eventY/accel_x_mag_falling_en > What: /sys/.../deviceX:eventY/accel_y_mag_en > What: /sys/.../deviceX:eventY/accel_y_mag_rising_en > What: /sys/.../deviceX:eventY/accel_y_mag_falling_en > What: /sys/.../deviceX:eventY/accel_z_mag_en > What: /sys/.../deviceX:eventY/accel_z_mag_rising_en > What: /sys/.../deviceX:eventY/accel_z_mag_falling_en > What: /sys/.../deviceX:eventY/accel_x&y&z_mag_rising_en > What: /sys/.../deviceX:eventY/accel_x&y&z_mag_falling_en > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Similar to accel_x_thresh[_rising|_falling]_en, but here the > magnitude of the channel is compared to the threshold, not its > signed value. > > What: /sys/.../accel_raw_mag_value > What: /sys/.../accel_x_raw_mag_rising_value > What: /sys/.../accel_y_raw_mag_rising_value > What: /sys/.../accel_z_raw_mag_rising_value > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > The value to which the magnitude of the channel is compared. If > number or direction is not specified, applies to all channels of > this type. > > What: /sys/bus/iio/devices/deviceX:buffer:event/dev > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Buffer for device X event character device major:minor numbers. > > What: /sys/bus/iio/devices/deviceX:buffer:access/dev > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Buffer for device X access character device major:minor numbers. > > What: /sys/bus/iio/devices/deviceX:buffer/trigger > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > The name of the trigger source being used, as per string given > in /sys/class/iio/triggerY/name. > > What: /sys/bus/iio/devices/deviceX:buffer/length > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Number of scans contained by the buffer. > > What: /sys/bus/iio/devices/deviceX:buffer/bytes_per_datum > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Bytes per scan. Due to alignment fun, the scan may be larger > than implied directly by the scan_element parameters. > > What: /sys/bus/iio/devices/deviceX:buffer/enable > KernelVersion: 2.6.35 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Actually start the buffer capture up. Will start trigger > if first device and appropriate. > > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Directory containing interfaces for elements that will be > captured for a single triggered sample set in the buffer. > > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_x_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_y_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_z_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_x_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_y_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_z_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_x_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_y_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_z_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/timestamp_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/inY_supply_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/inY_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/inY-inZ_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/incli_x_en > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/incli_y_en > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Scan element control for triggered data capture. > > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_type > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_type > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_type > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/incli_type > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/inY_type > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/in-in_type > What: /sys/.../deviceX:buffer/scan_elements/inY_supply_type > What: /sys/.../deviceX:buffer/scan_elements/timestamp_type > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > Description of the scan element data storage within the buffer > and hence the form in which it is read from user-space. > Form is [s|u]bits/storagebits[>>shift]. s or u specifies if > signed (2's complement) or unsigned. bits is the number of bits > of data and storagebits is the space (after padding) that it > occupies in the buffer. shift if specified, is the shift that > needs to be applied prior to masking out unused bits. Some > devices put their data in the middle of the transfered elements > with additional information on both sides. Note that some > devices will have additional information in the unused bits > so to get a clean value, the bits value must be used to mask > the buffer output value appropriately. The storagebits value > also specifies the data alignment. So s48/64>>2 will be a > signed 48 bit integer stored in a 64 bit location aligned to > a a64 bit boundary. To obtain the clean value, shift right 2 > and apply a mask to zero the top 16 bits of the result. > For other storage combinations this attribute will be extended > appropriately. > > What: /sys/.../deviceX:buffer/scan_elements/accel_type_available > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > If the type parameter can take one of a small set of values, > this attribute lists them. > > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/inY_index > What: /sys/.../deviceX:buffer/scan_elements/inY_supply_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_x_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_y_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/accel_z_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_x_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_y_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/gyro_z_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_x_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_y_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/magn_z_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/incli_x_index > What: /sys/bus/iio/devices/deviceX:buffer/scan_elements/incli_y_index > What: /sys/.../deviceX:buffer/scan_elements/timestamp_index > KernelVersion: 2.6.37 > Contact: linux-iio@xxxxxxxxxxxxxxx > Description: > A single positive integer specifying the position of this > scan element in the buffer. Note these are not dependent on > what is enabled and may not be contiguous. Thus for user-space > to establish the full layout these must be used in conjunction > with all _en attributes to establish which channels are present, > and the relevant _type attributes to establish the data storage > format. > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
