2 What: /sys/bus/iio/devices/device[n]
4 Contact: linux-iio@vger.kernel.org
6 Hardware chip or device accessed by on communication port.
7 Corresponds to a grouping of sensor channels.
9 What: /sys/bus/iio/devices/trigger[n]
11 Contact: linux-iio@vger.kernel.org
13 An event driven driver of data capture to an in kernel buffer.
14 May be provided by a device driver that also has an IIO device
15 based on hardware generated events (e.g. data ready) or
16 provided by a separate driver for other hardware (e.g.
17 periodic timer, gpio or high resolution timer).
18 Contains trigger type specific elements. These do not
19 generalize well and hence are not documented in this file.
21 What: /sys/bus/iio/devices/device[n]:buffer
23 Contact: linux-iio@vger.kernel.org
25 Link to /sys/class/iio/device[n]/device[n]:buffer. n indicates the
26 device with which this buffer buffer is associated.
28 What: /sys/.../device[n]/name
30 Contact: linux-iio@vger.kernel.org
32 Description of the physical chip / device. Typically a part
35 What: /sys/.../device[n]/sampling_frequency
37 Contact: linux-iio@vger.kernel.org
39 Some devices have internal clocks. This parameter sets the
40 resulting sampling frequency. In many devices this
41 parameter has an effect on input filters etc rather than
42 simply controlling when the input is sampled. As this
43 effects datardy triggers, hardware buffers and the sysfs
44 direct access interfaces, it may be found in any of the
45 relevant directories. If it effects all of the above
46 then it is to be found in the base device directory as here.
48 What: /sys/.../device[n]/sampling_frequency_available
50 Contact: linux-iio@vger.kernel.org
52 When the internal sampling clock can only take a small
53 discrete set of values, this file lists those availale.
55 What: /sys/.../device[n]/in[_name][m]_raw
57 Contact: linux-iio@vger.kernel.org
59 Raw (unscaled no bias removal etc) voltage measurement from
60 channel m. name is used in special cases where this does
61 not correspond to externally available input (e.g. supply
62 voltage monitoring in which case the file is in_supply_raw).
64 What: /sys/.../device[n]/in[_name][m]_offset
66 Contact: linux-iio@vger.kernel.org
68 If known for a device, offset to be added to in[m]_raw prior
69 to scaling by in[_name][m]_scale in order to obtain voltage in
70 millivolts. Not present if the offset is always 0 or unknown.
71 If m is not present, then voltage offset applies to all in
72 channels. May be writable if a variable offset is controlled
73 by the device. Note that this is different to calibbias which
74 is for devices that apply offsets to compensate for variation
75 between different instances of the part, typically adjusted by
76 using some hardware supported calibration procedure.
78 What: /sys/.../device[n]/in[_name][m]_offset_available
80 Contact: linux-iio@vger.kernel.org
82 If a small number of discrete offset values are available, this
83 will be a space separated list. If these are independant (but
84 options the same) for individual offsets then m should not be
87 What: /sys/.../device[n]/in[_name][m]_offset_[min|max]
89 Contact: linux-iio@vger.kernel.org
91 If a more or less continuous range of voltage offsets are supported
92 then these specify the minimum and maximum. If shared by all
93 in channels then m is not present.
95 What: /sys/.../device[n]/in[_name][m]_calibbias
97 Contact: linux-iio@vger.kernel.org
99 Hardware applied calibration offset. (assumed to fix production
102 What /sys/.../device[n]/in[_name][m]_calibscale
103 KernelVersion: 2.6.35
104 Contact: linux-iio@vger.kernel.org
106 Hardware applied calibration scale factor. (assumed to fix production
109 What: /sys/.../device[n]/in[_name][m]_scale
110 KernelVersion: 2.6.35
111 Contact: linux-iio@vger.kernel.org
113 If known for a device, scale to be applied to volt[m]_raw post
114 addition of in[_name][m]_offset in order to obtain the measured
115 voltage in millivolts. If shared across all in channels then m is not present.
117 What: /sys/.../device[n]/in[m]-in[o]_raw
118 KernelVersion: 2.6.35
119 Contact: linux-iio@vger.kernel.org
121 Raw (unscaled) differential voltage measurement equivalent to
122 channel m - channel o where these channel numbers apply to the physically
123 equivalent inputs when non differential readings are separately available.
124 In differential only parts, then all that is required is a consistent
127 What: /sys/.../device[n]/accel[_x|_y|_z][m]_raw
128 KernelVersion: 2.6.35
129 Contact: linux-iio@vger.kernel.org
131 Acceleration in direction x, y or z (may be arbitrarily assigned
132 but should match other such assignments on device)
133 channel m (not present if only one accelerometer channel at
134 this orientation). Has all of the equivalent parameters as per in[m].
135 Units after application of scale and offset are m/s^2.
137 What: /sys/.../device[n]/gyro[_x|_y|_z][m]_raw
138 KernelVersion: 2.6.35
139 Contact: linux-iio@vger.kernel.org
141 Angular velocity about axis x, y or z (may be arbitrarily assigned)
142 channel m (not present if only one gyroscope at this orientation).
143 Data converted by application of offset then scale to
144 radians per second. Has all the equivalent parameters as per in[m].
146 What: /sys/.../device[n]/incli[_x|_y|_z][m]_raw
147 KernelVersion: 2.6.35
148 Contact: linux-iio@vger.kernel.org
150 Inclination raw reading about axis x, y or z (may be arbitarily
151 assigned) channel m (not present if only one inclinometer at
152 this orientation). Data converted by application of offset
153 and scale to Degrees.
155 What: /sys/.../device[n]/magn[_x|_y|_z][m]_raw
156 KernelVersion: 2.6.35
157 Contact: linux-iio@vger.kernel.org
159 Magnetic field along axis x, y or z (may be arbitrarily assigned)
160 channel m (not present if only one magnetometer at this orientation).
161 Data converted by application of offset then scale to Gauss.
162 Has all the equivalent modifiers as per in[m].
164 What: /sys/.../device[n]/device[n]:event[m]
165 KernelVersion: 2.6.35
166 Contact: linux-iio@vger.kernel.org
168 Configuration of which hardware generated events are passed up to
169 userspace. Some of these are a bit complex to generalize so this
170 section is a work in progress.
172 What: /sys/.../device[n]:event[m]/dev
173 KernelVersion: 2.6.35
174 Contact: linux-iio@vger.kernel.org
176 major:minor character device numbers for the event line.
178 Taking accel_x0 as an example
180 What: /sys/.../device[n]:event[m]/accel_x0_thresh[_high|_low]_en
181 KernelVersion: 2.6.35
182 Contact: linux-iio@vger.kernel.org
184 Event generated when accel_x0 passes a threshold in correction direction
185 (or stays beyond one). If direction isn't specified, either triggers it.
186 Note driver will assume last p events requested are enabled where p is
187 however many it supports. So if you want to be sure you have
188 set what you think you have, check the contents of these. Drivers
189 may have to buffer any parameters so that they are consistent when a
190 given event type is enabled a future point (and not those for whatever
191 alarm was previously enabled).
193 What: /sys/.../device[n]:event[m]/accel_x0_roc[_high|_low]_en
194 KernelVersion: 2.6.35
195 Contact: linux-iio@vger.kernel.org
197 Same as above but based on the first differential of the value.
200 What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_period
201 KernelVersion: 2.6.35
202 Contact: linux-iio@vger.kernel.org
204 A period of time (microsecs) for which the condition must be broken
205 before an interrupt is triggered. Applies to all alarms if type is not
208 What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_value
209 KernelVersion: 2.6.35
210 Contact: linux-iio@vger.kernel.org
212 The actual value of the threshold in raw device units obtained by
213 reverse application of scale and offfset to the acceleration in m/s^2.
215 What: /sys/.../device[n]/device[n]:buffer:event/dev
216 KernelVersion: 2.6.35
217 Contact: linux-iio@vger.kernel.org
219 Buffer for device n event character device major:minor numbers.
221 What: /sys/.../device[n]/device[n]:buffer:access/dev
222 KernelVersion: 2.6.35
223 Contact: linux-iio@vger.kernel.org
225 Buffer for device n access character device o major:minor numbers.
227 What: /sys/.../device[n]:buffer/trigger
228 KernelVersion: 2.6.35
229 Contact: linux-iio@vger.kernel.org
231 The name of the trigger source being used, as per string given
232 in /sys/class/iio/trigger[n]/name.
234 What: /sys/.../device[n]:buffer/length
235 KernelVersion: 2.6.35
236 Contact: linux-iio@vger.kernel.org
238 Number of scans contained by the buffer.
240 What: /sys/.../device[n]:buffer/bytes_per_datum
241 KernelVersion: 2.6.37
242 Contact: linux-iio@vger.kernel.org
244 Bytes per scan. Due to alignment fun, the scan may be larger
245 than implied directly by the scan_element parameters.
247 What: /sys/.../device[n]:buffer/enable
248 KernelVersion: 2.6.35
249 Contact: linux-iio@vger.kernel.org
251 Actually start the buffer capture up. Will start trigger
252 if first device and appropriate.
254 What: /sys/.../device[n]:buffer/alignment
255 KernelVersion: 2.6.35
256 Contact: linux-iio@vger.kernel.org
258 Minimum data alignment. Scan elements larger than this are aligned
259 to the nearest power of 2 times this. (may not be true in weird
260 hardware buffers that pack data well)
262 What: /sys/.../device[n]/buffer/scan_elements
263 KernelVersion: 2.6.37
264 Contact: linux-iio@vger.kernel.org
266 Directory containing interfaces for elements that will be captured
267 for a single triggered sample set in the buffer.
269 What: /sys/.../device[n]/buffer/scan_elements/[m]_accel_x0_en
270 KernelVersion: 2.6.37
271 Contact: linux-iio@vger.kernel.org
273 Scan element control for triggered data capture. m implies the
274 ordering within the buffer. Next the type is specified with
275 modifier and channel number as per the sysfs single channel
278 What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_precision
279 KernelVersion: 2.6.37
280 Contact: linux-iio@vger.kernel.org
282 Scan element precision within the buffer. Note that the
283 data alignment must restrictions must be read from within
284 buffer to work out full data alignment for data read
285 via buffer_access chrdev. _x0 dropped if shared across all
286 acceleration channels.
288 What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_shift
289 KernelVersion: 2.6.37
290 Contact: linux-iio@vger.kernel.org
292 A bit shift (to right) that must be applied prior to
293 extracting the bits specified by accel[_x0]_precision.