blob: 714b4c57c82aba8ce6905dc32491d22ff31191ed [file] [log] [blame]
Jonathan Camerone34d2c52010-05-04 14:43:05 +01001
2What: /sys/bus/iio/devices/device[n]
3KernelVersion: 2.6.35
4Contact: linux-iio@vger.kernel.org
5Description:
6 Hardware chip or device accessed by on communication port.
7 Corresponds to a grouping of sensor channels.
8
9What: /sys/bus/iio/devices/trigger[n]
10KernelVersion: 2.6.35
11Contact: linux-iio@vger.kernel.org
12Description:
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.
20
21What: /sys/bus/iio/devices/device[n]:buffer
22KernelVersion: 2.6.35
23Contact: linux-iio@vger.kernel.org
24Description:
25 Link to /sys/class/iio/device[n]/device[n]:buffer. n indicates the
26 device with which this buffer buffer is associated.
27
28What: /sys/.../device[n]/name
29KernelVersion: 2.6.35
30Contact: linux-iio@vger.kernel.org
31Description:
32 Description of the physical chip / device. Typically a part
33 number.
34
35What: /sys/.../device[n]/sampling_frequency
36KernelVersion: 2.6.35
37Contact: linux-iio@vger.kernel.org
38Description:
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.
47
48What: /sys/.../device[n]/sampling_frequency_available
49KernelVersion: 2.6.35
50Contact: linux-iio@vger.kernel.org
51Description:
52 When the internal sampling clock can only take a small
53 discrete set of values, this file lists those availale.
54
55What: /sys/.../device[n]/in[_name][m]_raw
56KernelVersion: 2.6.35
57Contact: linux-iio@vger.kernel.org
58Description:
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).
63
64What: /sys/.../device[n]/in[_name][m]_offset
65KernelVersion: 2.6.35
66Contact: linux-iio@vger.kernel.org
67Description:
68 If known for a device, offset to be added to in[m]_raw prior
Jonathan Cameron85798ec2010-05-07 15:38:54 +010069 to scaling by in[_name][m]_scale in order to obtain voltage in
Jonathan Camerone34d2c52010-05-04 14:43:05 +010070 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.
77
78What: /sys/.../device[n]/in[_name][m]_offset_available
79KernelVersion: 2.6.35
80Contact: linux-iio@vger.kernel.org
81Description:
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
85 present.
86
87What: /sys/.../device[n]/in[_name][m]_offset_[min|max]
88KernelVersion: 2.6.35
89Contact: linux-iio@vger.kernel.org
90Description:
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.
94
95What: /sys/.../device[n]/in[_name][m]_calibbias
96KernelVersion: 2.6.35
97Contact: linux-iio@vger.kernel.org
98Description:
99 Hardware applied calibration offset. (assumed to fix production
100 inaccuracies)
101
102What /sys/.../device[n]/in[_name][m]_calibscale
103KernelVersion: 2.6.35
104Contact: linux-iio@vger.kernel.org
105Description:
106 Hardware applied calibration scale factor. (assumed to fix production
107 inaccuracies)
108
109What: /sys/.../device[n]/in[_name][m]_scale
110KernelVersion: 2.6.35
111Contact: linux-iio@vger.kernel.org
112Description:
113 If known for a device, scale to be applied to volt[m]_raw post
Jonathan Cameron85798ec2010-05-07 15:38:54 +0100114 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.
Jonathan Camerone34d2c52010-05-04 14:43:05 +0100116
117What: /sys/.../device[n]/in[m]-in[o]_raw
118KernelVersion: 2.6.35
119Contact: linux-iio@vger.kernel.org
120Description:
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
125 labelling.
126
127What: /sys/.../device[n]/accel[_x|_y|_z][m]_raw
128KernelVersion: 2.6.35
129Contact: linux-iio@vger.kernel.org
130Description:
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.
136
137What: /sys/.../device[n]/gyro[_x|_y|_z][m]_raw
138KernelVersion: 2.6.35
139Contact: linux-iio@vger.kernel.org
140Description:
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].
145
Jonathan Camerone5107fb2010-05-07 15:38:57 +0100146What: /sys/.../device[n]/incli[_x|_y|_z][m]_raw
147KernelVersion: 2.6.35
148Contact: linux-iio@vger.kernel.org
149Description:
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.
154
155What: /sys/.../device[n]/magn[_x|_y|_z][m]_raw
Jonathan Camerone34d2c52010-05-04 14:43:05 +0100156KernelVersion: 2.6.35
157Contact: linux-iio@vger.kernel.org
158Description:
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].
163
164What: /sys/.../device[n]/device[n]:event[m]
165KernelVersion: 2.6.35
166Contact: linux-iio@vger.kernel.org
167Description:
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.
171
172What: /sys/.../device[n]:event[m]/dev
173KernelVersion: 2.6.35
174Contact: linux-iio@vger.kernel.org
175Description:
176 major:minor character device numbers for the event line.
177
178Taking accel_x0 as an example
179
180What: /sys/.../device[n]:event[m]/accel_x0_thresh[_high|_low]_en
181KernelVersion: 2.6.35
182Contact: linux-iio@vger.kernel.org
183Description:
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).
192
193What: /sys/.../device[n]:event[m]/accel_x0_roc[_high|_low]_en
194KernelVersion: 2.6.35
195Contact: linux-iio@vger.kernel.org
196Description:
197 Same as above but based on the first differential of the value.
198
199
200What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_period
201KernelVersion: 2.6.35
202Contact: linux-iio@vger.kernel.org
203Description:
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
206 specified.
207
208What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_value
209KernelVersion: 2.6.35
210Contact: linux-iio@vger.kernel.org
211Description:
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.
214
215What: /sys/.../device[n]/scan_elements
216KernelVersion: 2.6.35
217Contact: linux-iio@vger.kernel.org
218Description:
219 Directory containing interfaces for elements that will be captured
220 for a single triggered sample set in the buffer.
221
222What: /sys/.../device[n]/scan_elements/[m]_accel_x0_en
223KernelVersion: 2.6.35
224Contact: linux-iio@vger.kernel.org
225Description:
226 Scan element control for triggered data capture. m implies the
227 ordering within the buffer. Next the type is specified with
228 modifier and channel number as per the sysfs single channel
229 access above.
230
231What: /sys/.../device[n]/scan_elements/accel[_x0]_precision
232KernelVersion: 2.6.35
233Contact: linux-iio@vger.kernel.org
234Description:
235 Scan element precision within the buffer. Note that the
236 data alignment must restrictions must be read from within
237 buffer to work out full data alignment for data read
238 via buffer_access chrdev. _x0 dropped if shared across all
239 acceleration channels.
240
241What: /sys/.../device[n]/scan_elements/accel[_x0]_shift
242KernelVersion: 2.6.35
243Contact: linux-iio@vger.kernel.org
244Description:
245 A bit shift (to right) that must be applied prior to
246 extracting the bits specified by accel[_x0]_precision.
247
248What: /sys/.../device[n]/device[n]:buffer:event/dev
249KernelVersion: 2.6.35
250Contact: linux-iio@vger.kernel.org
251Description:
252 Buffer for device n event character device major:minor numbers.
253
254What: /sys/.../device[n]/device[n]:buffer:access/dev
255KernelVersion: 2.6.35
256Contact: linux-iio@vger.kernel.org
257Description:
258 Buffer for device n access character device o major:minor numbers.
259
260What: /sys/.../device[n]:buffer/trigger
261KernelVersion: 2.6.35
262Contact: linux-iio@vger.kernel.org
263Description:
264 The name of the trigger source being used, as per string given
265 in /sys/class/iio/trigger[n]/name.
266
267What: /sys/.../device[n]:buffer/length
268KernelVersion: 2.6.35
269Contact: linux-iio@vger.kernel.org
270Description:
271 Number of scans contained by the buffer.
272
273What: /sys/.../device[n]:buffer/bps
274KernelVersion: 2.6.35
275Contact: linux-iio@vger.kernel.org
276Description:
277 Bytes per scan. Due to alignment fun, the scan may be larger
278 than implied directly by the scan_element parameters.
279
280What: /sys/.../device[n]:buffer/enable
281KernelVersion: 2.6.35
282Contact: linux-iio@vger.kernel.org
283Description:
284 Actually start the buffer capture up. Will start trigger
285 if first device and appropriate.
286
287What: /sys/.../device[n]:buffer/alignment
288KernelVersion: 2.6.35
289Contact: linux-iio@vger.kernel.org
290Description:
291 Minimum data alignment. Scan elements larger than this are aligned
292 to the nearest power of 2 times this. (may not be true in weird
293 hardware buffers that pack data well)
294