staging: iio: lis3l02dqbuffersimple.c bring example up to date.
[linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git] / drivers / staging / iio / Documentation / sysfs-class-iio
blobc13702037b089e776ac949aff6028e80ec3436b6
2 What:           /sys/bus/iio/devices/device[n]
3 KernelVersion:  2.6.35
4 Contact:        linux-iio@vger.kernel.org
5 Description:
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]
10 KernelVersion:  2.6.35
11 Contact:        linux-iio@vger.kernel.org
12 Description:
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
22 KernelVersion:  2.6.35
23 Contact:        linux-iio@vger.kernel.org
24 Description:
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
29 KernelVersion:  2.6.35
30 Contact:        linux-iio@vger.kernel.org
31 Description:
32                 Description of the physical chip / device. Typically a part
33                 number.
35 What:           /sys/.../device[n]/sampling_frequency
36 KernelVersion:  2.6.35
37 Contact:        linux-iio@vger.kernel.org
38 Description:
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
49 KernelVersion:  2.6.35
50 Contact:        linux-iio@vger.kernel.org
51 Description:
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
56 KernelVersion:  2.6.35
57 Contact:        linux-iio@vger.kernel.org
58 Description:
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
65 KernelVersion:  2.6.35
66 Contact:        linux-iio@vger.kernel.org
67 Description:
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
79 KernelVersion:  2.6.35
80 Contact:        linux-iio@vger.kernel.org
81 Description:
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.
87 What:           /sys/.../device[n]/in[_name][m]_offset_[min|max]
88 KernelVersion:  2.6.35
89 Contact:        linux-iio@vger.kernel.org
90 Description:
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
96 KernelVersion:  2.6.35
97 Contact:        linux-iio@vger.kernel.org
98 Description:
99                 Hardware applied calibration offset. (assumed to fix production
100                 inaccuracies)
102 What            /sys/.../device[n]/in[_name][m]_calibscale
103 KernelVersion:  2.6.35
104 Contact:        linux-iio@vger.kernel.org
105 Description:
106                 Hardware applied calibration scale factor. (assumed to fix production
107                 inaccuracies)
109 What:           /sys/.../device[n]/in[_name][m]_scale
110 KernelVersion:  2.6.35
111 Contact:        linux-iio@vger.kernel.org
112 Description:
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
120 Description:
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.
127 What:           /sys/.../device[n]/accel[_x|_y|_z][m]_raw
128 KernelVersion:  2.6.35
129 Contact:        linux-iio@vger.kernel.org
130 Description:
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
140 Description:
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
149 Description:
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
158 Description:
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
167 Description:
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
175 Description:
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
183 Description:
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
196 Description:
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
203 Description:
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.
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
211 Description:
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
218 Description:
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
224 Description:
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
230 Description:
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
237 Description:
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
243 Description:
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
250 Description:
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
257 Description:
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
265 Description:
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
272 Description:
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
276                 access above.
278 What:           /sys/.../device[n]/buffer/scan_elements/accel[_x0]_precision
279 KernelVersion:  2.6.37
280 Contact:        linux-iio@vger.kernel.org
281 Description:
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
291 Description:
292                 A bit shift (to right) that must be applied prior to
293                 extracting the bits specified by accel[_x0]_precision.