1 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 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. 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 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. 116 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 146What: /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 156KernelVersion: 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 295