Jonathan Cameron | e34d2c5 | 2010-05-04 14:43:05 +0100 | [diff] [blame] | 1 | |
| 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. |
| 8 | |
| 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. |
| 20 | |
| 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. |
| 27 | |
| 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. |
| 34 | |
| 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. |
| 47 | |
| 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. |
| 54 | |
| 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). |
| 63 | |
| 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 |
Jonathan Cameron | 85798ec | 2010-05-07 15:38:54 +0100 | [diff] [blame] | 69 | to scaling by in[_name][m]_scale in order to obtain voltage in |
Jonathan Cameron | e34d2c5 | 2010-05-04 14:43:05 +0100 | [diff] [blame] | 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 | |
| 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. |
| 86 | |
| 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. |
| 94 | |
| 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) |
| 101 | |
| 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) |
| 108 | |
| 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 |
Jonathan Cameron | 85798ec | 2010-05-07 15:38:54 +0100 | [diff] [blame] | 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. |
Jonathan Cameron | e34d2c5 | 2010-05-04 14:43:05 +0100 | [diff] [blame] | 116 | |
| 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. |
| 126 | |
| 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. |
| 136 | |
| 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]. |
| 145 | |
Jonathan Cameron | e5107fb | 2010-05-07 15:38:57 +0100 | [diff] [blame^] | 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. |
| 154 | |
| 155 | What: /sys/.../device[n]/magn[_x|_y|_z][m]_raw |
Jonathan Cameron | e34d2c5 | 2010-05-04 14:43:05 +0100 | [diff] [blame] | 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]. |
| 163 | |
| 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. |
| 171 | |
| 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. |
| 177 | |
| 178 | Taking accel_x0 as an example |
| 179 | |
| 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). |
| 192 | |
| 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. |
| 198 | |
| 199 | |
| 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. |
| 207 | |
| 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. |
| 214 | |
| 215 | What: /sys/.../device[n]/scan_elements |
| 216 | KernelVersion: 2.6.35 |
| 217 | Contact: linux-iio@vger.kernel.org |
| 218 | Description: |
| 219 | Directory containing interfaces for elements that will be captured |
| 220 | for a single triggered sample set in the buffer. |
| 221 | |
| 222 | What: /sys/.../device[n]/scan_elements/[m]_accel_x0_en |
| 223 | KernelVersion: 2.6.35 |
| 224 | Contact: linux-iio@vger.kernel.org |
| 225 | Description: |
| 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 | |
| 231 | What: /sys/.../device[n]/scan_elements/accel[_x0]_precision |
| 232 | KernelVersion: 2.6.35 |
| 233 | Contact: linux-iio@vger.kernel.org |
| 234 | Description: |
| 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 | |
| 241 | What: /sys/.../device[n]/scan_elements/accel[_x0]_shift |
| 242 | KernelVersion: 2.6.35 |
| 243 | Contact: linux-iio@vger.kernel.org |
| 244 | Description: |
| 245 | A bit shift (to right) that must be applied prior to |
| 246 | extracting the bits specified by accel[_x0]_precision. |
| 247 | |
| 248 | What: /sys/.../device[n]/device[n]:buffer:event/dev |
| 249 | KernelVersion: 2.6.35 |
| 250 | Contact: linux-iio@vger.kernel.org |
| 251 | Description: |
| 252 | Buffer for device n event character device major:minor numbers. |
| 253 | |
| 254 | What: /sys/.../device[n]/device[n]:buffer:access/dev |
| 255 | KernelVersion: 2.6.35 |
| 256 | Contact: linux-iio@vger.kernel.org |
| 257 | Description: |
| 258 | Buffer for device n access character device o major:minor numbers. |
| 259 | |
| 260 | What: /sys/.../device[n]:buffer/trigger |
| 261 | KernelVersion: 2.6.35 |
| 262 | Contact: linux-iio@vger.kernel.org |
| 263 | Description: |
| 264 | The name of the trigger source being used, as per string given |
| 265 | in /sys/class/iio/trigger[n]/name. |
| 266 | |
| 267 | What: /sys/.../device[n]:buffer/length |
| 268 | KernelVersion: 2.6.35 |
| 269 | Contact: linux-iio@vger.kernel.org |
| 270 | Description: |
| 271 | Number of scans contained by the buffer. |
| 272 | |
| 273 | What: /sys/.../device[n]:buffer/bps |
| 274 | KernelVersion: 2.6.35 |
| 275 | Contact: linux-iio@vger.kernel.org |
| 276 | Description: |
| 277 | Bytes per scan. Due to alignment fun, the scan may be larger |
| 278 | than implied directly by the scan_element parameters. |
| 279 | |
| 280 | What: /sys/.../device[n]:buffer/enable |
| 281 | KernelVersion: 2.6.35 |
| 282 | Contact: linux-iio@vger.kernel.org |
| 283 | Description: |
| 284 | Actually start the buffer capture up. Will start trigger |
| 285 | if first device and appropriate. |
| 286 | |
| 287 | What: /sys/.../device[n]:buffer/alignment |
| 288 | KernelVersion: 2.6.35 |
| 289 | Contact: linux-iio@vger.kernel.org |
| 290 | Description: |
| 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 | |