--- /dev/null
+What: /sys/bus/iio/devices/device[n]
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware chip or device accessed by on communication port.
+ Corresponds to a grouping of sensor channels.
+
+What: /sys/bus/iio/devices/trigger[n]
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ An event driven driver of data capture to an in kernel buffer.
+ May be provided by a device driver that also has an IIO device
+ based on hardware generated events (e.g. data ready) or
+ provided by a separate driver for other hardware (e.g.
+ periodic timer, gpio or high resolution timer).
+ Contains trigger type specific elements. These do not
+ generalize well and hence are not documented in this file.
+
+What: /sys/bus/iio/devices/device[n]:buffer
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Link to /sys/class/iio/device[n]/device[n]:buffer. n indicates
+ the device with which this buffer buffer is associated.
+
+What: /sys/.../device[n]/name
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Description of the physical chip / device. Typically a part
+ number.
+
+What: /sys/.../device[n]/sampling_frequency
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+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/.../device[n]/sampling_frequency_available
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ When the internal sampling clock can only take a small
+ discrete set of values, this file lists those availale.
+
+What: /sys/.../device[n]/in[m][_name]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled no bias removal etc) voltage measurement from
+ channel m. name is used in special cases where this does
+ not correspond to externally available input (e.g. supply
+ voltage monitoring in which case the file is in_supply_raw).
+ If the device supports events on this channel then m must be
+ specified (even on named channels) so as to allow the source
+ of event codes to be identified.
+
+What: /sys/.../device[n]/in[m][_name]_offset
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ If known for a device, offset to be added to in[m]_raw prior
+ to scaling by in[_name][m]_scale in order to obtain voltage in
+ millivolts. Not present if the offset is always 0 or unknown.
+ If m is not present, then voltage offset applies to all in
+ channels. May be writable if a variable offset is controlled
+ by the device. Note that this is different to calibbias which
+ is for devices that apply offsets to compensate for variation
+ between different instances of the part, typically adjusted by
+ using some hardware supported calibration procedure.
+
+What: /sys/.../device[n]/in[m][_name]_offset_available
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ If a small number of discrete offset values are available, this
+ will be a space separated list. If these are independant (but
+ options the same) for individual offsets then m should not be
+ present.
+
+What: /sys/.../device[n]/in[m][_name]_offset_[min|max]
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ If a more or less continuous range of voltage offsets are
+ supported then these specify the minimum and maximum. If shared
+ by all in channels then m is not present.
+
+What: /sys/.../device[n]/in[m][_name]_calibbias
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware applied calibration offset. (assumed to fix production
+ inaccuracies)
+
+What /sys/.../device[n]/in[m][_name]_calibscale
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware applied calibration scale factor. (assumed to fix
+ production inaccuracies)
+
+What: /sys/.../device[n]/in[m][_name]_scale
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ If known for a device, scale to be applied to volt[m]_raw post
+ addition of in[_name][m]_offset in order to obtain the measured
+ voltage in millivolts. If shared across all in channels then
+ m is not present.
+
+What: /sys/.../device[n]/in[m]-in[o]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled) differential voltage measurement equivalent to
+ channel m - channel o where these channel numbers apply to the
+ physically equivalent inputs when non differential readings are
+ separately available. In differential only parts, then all that
+ is required is a consistent labelling.
+
+What: /sys/.../device[n]/accel[_x|_y|_z][m]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Acceleration in direction x, y or z (may be arbitrarily assigned
+ but should match other such assignments on device)
+ channel m (not present if only one accelerometer channel at
+ this orientation). Has all of the equivalent parameters as per
+ in[m]. Units after application of scale and offset are m/s^2.
+
+What: /sys/.../device[n]/gyro[_x|_y|_z][m]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Angular velocity about axis x, y or z (may be arbitrarily
+ assigned) channel m (not present if only one gyroscope at
+ this orientation).
+ Data converted by application of offset then scale to
+ radians per second. Has all the equivalent parameters as
+ per in[m].
+
+What: /sys/.../device[n]/incli[_x|_y|_z][m]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Inclination raw reading about axis x, y or z (may be arbitarily
+ assigned) channel m (not present if only one inclinometer at
+ this orientation). Data converted by application of offset
+ and scale to Degrees.
+
+What: /sys/.../device[n]/magn[_x|_y|_z][m]_raw
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Magnetic field along axis x, y or z (may be arbitrarily
+ assigned) channel m (not present if only one magnetometer
+ at this orientation). Data converted by application of
+ offset then scale to Gauss. Has all the equivalent modifiers
+ as per in[m].
+
+What: /sys/.../device[n]/device[n]:event[m]
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Configuration of which hardware generated events are passed up to
+ userspace. Some of these are a bit complex to generalize so this
+ section is a work in progress.
+
+What: /sys/.../device[n]:event[m]/dev
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ major:minor character device numbers for the event line.
+
+Taking accel_x0 as an example
+
+What: /sys/.../device[n]:event[m]/accel_x0_thresh[_rising|_falling]_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Event generated when accel_x0 passes a threshold in the specfied
+ (_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.
+ accel_x0_<raw|input>_thresh_value) or
+ accel_x0_<raw|input>_thresh_rising_value and
+ accel_x0_<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/.../accel_x0_<raw|input>_thresh[_rising|_falling]_value
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies the value of threshold that the device is comparing
+ against for the events enabled by
+ accel_x0_<raw|input>_thresh[_rising|falling]_en.
+ If seperate 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/.../accel_x0_thresh[_rising|_falling]_meanperiod
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) over which the raw channel value
+ is averaged before being compared with the threshold set in
+ accel_x0_thresh[_rising|_falling]_meanperiod. If direction is
+ not specified then this mean period applies to both directions.
+
+What: /sys/.../accel_x0_thresh[_rising|_falling]_period
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) for which the threshold must be
+ passed before an event is generated. If direction is not
+ specified then this period applies to both directions.
+
+What: /sys/.../device[n]:event[m]/accel_x0_mag[_rising|_falling]_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Similar to accel_x0_thresh[_rising|_falling]_en, but here the
+ magnitude of the channel is compared to the threshold, not its
+ signed value.
+
+What: /sys/.../accel_x0_<raw|input>_mag[_rising|_falling]_value
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ The value to which the magnitude of the channel is compared.
+
+What: /sys/.../accel_x0_mag[_rising|_falling]_meanperiod
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) over which the value of the channel
+ is averaged before being compared to the threshold
+
+What: /sys/.../accel_x0_mag[_rising|_falling]_period
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) for which the condition must be true
+ before an event occurs.
+
+What: /sys/.../device[n]:event[m]/accel_x0_roc[_rising|_falling]_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Similar to accel_x0_thresh[_rising|_falling]_en, but here the
+ first differential is compared with the threshold.
+
+What: /sys/.../accel_x0_<raw|input>_roc[_rising|_falling]_value
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ The value to which the first differential of the channel is
+ compared.
+
+What: /sys/.../accel_x0_roc[_rising|_falling]_meanperiod
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) over which the value of the channel
+ is averaged before being compared to the threshold
+
+What: /sys/.../accel_x0_roc[_rising|_falling]_period
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Period of time (in seconds) for which the condition must be true
+ before an event occurs.
+
+What: /sys/.../device[n]/device[n]:buffer:event/dev
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Buffer for device n event character device major:minor numbers.
+
+What: /sys/.../device[n]/device[n]:buffer:access/dev
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Buffer for device n access character device o major:minor numbers.
+
+What: /sys/.../device[n]:buffer/trigger
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ The name of the trigger source being used, as per string given
+ in /sys/class/iio/trigger[n]/name.
+
+What: /sys/.../device[n]:buffer/length
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Number of scans contained by the buffer.
+
+What: /sys/.../device[n]:buffer/bytes_per_datum
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Bytes per scan. Due to alignment fun, the scan may be larger
+ than implied directly by the scan_element parameters.
+
+What: /sys/.../device[n]:buffer/enable
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Actually start the buffer capture up. Will start trigger
+ if first device and appropriate.
+
+What: /sys/.../device[n]:buffer/alignment
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ Minimum data alignment. Scan elements larger than this are
+ aligned to the nearest power of 2 times this. (may not be
+ true in weird hardware buffers that pack data well)
+
+What: /sys/.../device[n]/buffer/scan_elements
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Directory containing interfaces for elements that will be
+ captured for a single triggered sample set in the buffer.
+
+What: /sys/.../device[n]/buffer/scan_elements/accel_x0_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Scan element control for triggered data capture.
+
+What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_type
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Description of the scan element data storage within the buffer
+ and hence the form in which it is read from userspace.
+ Form is [s|u]bits/storagebits. 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. 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 will be a signed 48 bit integer
+ stored in a 64 bit location aligned to a a64 bit boundary.
+ For other storage combinations this attribute will be extended
+ appropriately.
+
+What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_index
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ A single positive integer specifying the position of this
+ scan element in the buffer. Note these are not dependant on
+ what is enabled and may not be contiguous. Thus for userspace
+ 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.
+
+What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_shift
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ A bit shift (to right) that must be applied prior to
+ extracting the bits specified by accel[_x0]_precision.
projects / mv-sheeva.git / blobdiff