Documentation/DocBook/iio.tmpl

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
   3         "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
   4
   5 <book id="iioid">
   6   <bookinfo>
   7     <title>Industrial I/O driver developer's guide </title>
   8
   9     <authorgroup>
  10       <author>
  11         <firstname>Daniel</firstname>
  12         <surname>Baluta</surname>
  13         <affiliation>
  14           <address>
  15             <email>daniel.baluta@intel.com</email>
  16           </address>
  17         </affiliation>
  18       </author>
  19     </authorgroup>
  20
  21     <copyright>
  22       <year>2015</year>
  23       <holder>Intel Corporation</holder>
  24     </copyright>
  25
  26     <legalnotice>
  27       <para>
  28         This documentation is free software; you can redistribute
  29         it and/or modify it under the terms of the GNU General Public
  30         License version 2.
  31       </para>
  32     </legalnotice>
  33   </bookinfo>
  34
  35   <toc></toc>
  36
  37   <chapter id="intro">
  38     <title>Introduction</title>
  39     <para>
  40       The main purpose of the Industrial I/O subsystem (IIO) is to provide
  41       support for devices that in some sense perform either analog-to-digital
  42       conversion (ADC) or digital-to-analog conversion (DAC) or both. The aim
  43       is to fill the gap between the somewhat similar hwmon and input
  44       subsystems.
  45       Hwmon is directed at low sample rate sensors used to monitor and
  46       control the system itself, like fan speed control or temperature
  47       measurement. Input is, as its name suggests, focused on human interaction
  48       input devices (keyboard, mouse, touchscreen). In some cases there is
  49       considerable overlap between these and IIO.
  50   </para>
  51   <para>
  52     Devices that fall into this category include:
  53     <itemizedlist>
  54       <listitem>
  55         analog to digital converters (ADCs)
  56       </listitem>
  57       <listitem>
  58         accelerometers
  59       </listitem>
  60       <listitem>
  61         capacitance to digital converters (CDCs)
  62       </listitem>
  63       <listitem>
  64         digital to analog converters (DACs)
  65       </listitem>
  66       <listitem>
  67         gyroscopes
  68       </listitem>
  69       <listitem>
  70         inertial measurement units (IMUs)
  71       </listitem>
  72       <listitem>
  73         color and light sensors
  74       </listitem>
  75       <listitem>
  76         magnetometers
  77       </listitem>
  78       <listitem>
  79         pressure sensors
  80       </listitem>
  81       <listitem>
  82         proximity sensors
  83       </listitem>
  84       <listitem>
  85         temperature sensors
  86       </listitem>
  87     </itemizedlist>
  88     Usually these sensors are connected via SPI or I2C. A common use case of the
  89     sensors devices is to have combined functionality (e.g. light plus proximity
  90     sensor).
  91   </para>
  92   </chapter>
  93   <chapter id='iiosubsys'>
  94     <title>Industrial I/O core</title>
  95     <para>
  96       The Industrial I/O core offers:
  97       <itemizedlist>
  98         <listitem>
  99          a unified framework for writing drivers for many different types of
 100          embedded sensors.
 101         </listitem>
 102         <listitem>
 103          a standard interface to user space applications manipulating sensors.
 104         </listitem>
 105       </itemizedlist>
 106       The implementation can be found under <filename>
 107       drivers/iio/industrialio-*</filename>
 108   </para>
 109   <sect1 id="iiodevice">
 110     <title> Industrial I/O devices </title>
 111
 112 !Finclude/linux/iio/iio.h iio_dev
 113 !Fdrivers/iio/industrialio-core.c iio_device_alloc
 114 !Fdrivers/iio/industrialio-core.c iio_device_free
 115 !Fdrivers/iio/industrialio-core.c iio_device_register
 116 !Fdrivers/iio/industrialio-core.c iio_device_unregister
 117
 118     <para>
 119       An IIO device usually corresponds to a single hardware sensor and it
 120       provides all the information needed by a driver handling a device.
 121       Let's first have a look at the functionality embedded in an IIO
 122       device then we will show how a device driver makes use of an IIO
 123       device.
 124     </para>
 125     <para>
 126         There are two ways for a user space application to interact
 127         with an IIO driver.
 128       <itemizedlist>
 129         <listitem>
 130           <filename>/sys/bus/iio/iio:deviceX/</filename>, this
 131           represents a hardware sensor and groups together the data
 132           channels of the same chip.
 133         </listitem>
 134         <listitem>
 135           <filename>/dev/iio:deviceX</filename>, character device node
 136           interface used for buffered data transfer and for events information
 137           retrieval.
 138         </listitem>
 139       </itemizedlist>
 140     </para>
 141     A typical IIO driver will register itself as an I2C or SPI driver and will
 142     create two routines, <function> probe </function> and <function> remove
 143     </function>. At <function>probe</function>:
 144     <itemizedlist>
 145     <listitem>call <function>iio_device_alloc</function>, which allocates memory
 146       for an IIO device.
 147     </listitem>
 148     <listitem> initialize IIO device fields with driver specific information
 149               (e.g. device name, device channels).
 150     </listitem>
 151     <listitem>call <function> iio_device_register</function>, this registers the
 152       device with the IIO core. After this call the device is ready to accept
 153       requests from user space applications.
 154     </listitem>
 155     </itemizedlist>
 156       At <function>remove</function>, we free the resources allocated in
 157       <function>probe</function> in reverse order:
 158     <itemizedlist>
 159     <listitem><function>iio_device_unregister</function>, unregister the device
 160       from the IIO core.
 161     </listitem>
 162     <listitem><function>iio_device_free</function>, free the memory allocated
 163       for the IIO device.
 164     </listitem>
 165     </itemizedlist>
 166
 167     <sect2 id="iioattr"> <title> IIO device sysfs interface </title>
 168       <para>
 169         Attributes are sysfs files used to expose chip info and also allowing
 170         applications to set various configuration parameters. For device
 171         with index X, attributes can be found under
 172         <filename>/sys/bus/iio/iio:deviceX/ </filename> directory.
 173         Common attributes are:
 174         <itemizedlist>
 175           <listitem><filename>name</filename>, description of the physical
 176             chip.
 177           </listitem>
 178           <listitem><filename>dev</filename>, shows the major:minor pair
 179             associated with <filename>/dev/iio:deviceX</filename> node.
 180           </listitem>
 181           <listitem><filename>sampling_frequency_available</filename>,
 182             available discrete set of sampling frequency values for
 183             device.
 184           </listitem>
 185       </itemizedlist>
 186       Available standard attributes for IIO devices are described in the
 187       <filename>Documentation/ABI/testing/sysfs-bus-iio </filename> file
 188       in the Linux kernel sources.
 189       </para>
 190     </sect2>
 191     <sect2 id="iiochannel"> <title> IIO device channels </title>
 192 !Finclude/linux/iio/iio.h iio_chan_spec structure.
 193       <para>
 194         An IIO device channel is a representation of a data channel. An
 195         IIO device can have one or multiple channels. For example:
 196         <itemizedlist>
 197           <listitem>
 198           a thermometer sensor has one channel representing the
 199           temperature measurement.
 200           </listitem>
 201           <listitem>
 202           a light sensor with two channels indicating the measurements in
 203           the visible and infrared spectrum.
 204           </listitem>
 205           <listitem>
 206           an accelerometer can have up to 3 channels representing
 207           acceleration on X, Y and Z axes.
 208           </listitem>
 209         </itemizedlist>
 210       An IIO channel is described by the <type> struct iio_chan_spec
 211       </type>. A thermometer driver for the temperature sensor in the
 212       example above would have to describe its channel as follows:
 213       <programlisting>
 214       static const struct iio_chan_spec temp_channel[] = {
 215           {
 216               .type = IIO_TEMP,
 217               .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
 218           },
 219       };
 220
 221       </programlisting>
 222       Channel sysfs attributes exposed to userspace are specified in
 223       the form of <emphasis>bitmasks</emphasis>. Depending on their
 224       shared info, attributes can be set in one of the following masks:
 225       <itemizedlist>
 226       <listitem><emphasis>info_mask_separate</emphasis>, attributes will
 227         be specific to this channel</listitem>
 228       <listitem><emphasis>info_mask_shared_by_type</emphasis>,
 229         attributes are shared by all channels of the same type</listitem>
 230       <listitem><emphasis>info_mask_shared_by_dir</emphasis>, attributes
 231         are shared by all channels of the same direction </listitem>
 232       <listitem><emphasis>info_mask_shared_by_all</emphasis>,
 233         attributes are shared by all channels</listitem>
 234       </itemizedlist>
 235       When there are multiple data channels per channel type we have two
 236       ways to distinguish between them:
 237       <itemizedlist>
 238       <listitem> set <emphasis> .modified</emphasis> field of <type>
 239         iio_chan_spec</type> to 1. Modifiers are specified using
 240         <emphasis>.channel2</emphasis> field of the same
 241         <type>iio_chan_spec</type> structure and are used to indicate a
 242         physically unique characteristic of the channel such as its direction
 243         or spectral response. For example, a light sensor can have two channels,
 244         one for infrared light and one for both infrared and visible light.
 245       </listitem>
 246       <listitem> set <emphasis>.indexed </emphasis> field of
 247         <type>iio_chan_spec</type> to 1. In this case the channel is
 248         simply another instance with an index specified by the
 249         <emphasis>.channel</emphasis> field.
 250       </listitem>
 251       </itemizedlist>
 252       Here is how we can make use of the channel's modifiers:
 253       <programlisting>
 254       static const struct iio_chan_spec light_channels[] = {
 255           {
 256               .type = IIO_INTENSITY,
 257               .modified = 1,
 258               .channel2 = IIO_MOD_LIGHT_IR,
 259               .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
 260               .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
 261           },
 262           {
 263               .type = IIO_INTENSITY,
 264               .modified = 1,
 265               .channel2 = IIO_MOD_LIGHT_BOTH,
 266               .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
 267               .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
 268           },
 269           {
 270               .type = IIO_LIGHT,
 271               .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
 272               .info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
 273           },
 274
 275       }
 276       </programlisting>
 277       This channel's definition will generate two separate sysfs files
 278       for raw data retrieval:
 279       <itemizedlist>
 280       <listitem>
 281       <filename>/sys/bus/iio/iio:deviceX/in_intensity_ir_raw</filename>
 282       </listitem>
 283       <listitem>
 284       <filename>/sys/bus/iio/iio:deviceX/in_intensity_both_raw</filename>
 285       </listitem>
 286       </itemizedlist>
 287       one file for processed data:
 288       <itemizedlist>
 289       <listitem>
 290       <filename>/sys/bus/iio/iio:deviceX/in_illuminance_input
 291       </filename>
 292       </listitem>
 293       </itemizedlist>
 294       and one shared sysfs file for sampling frequency:
 295       <itemizedlist>
 296       <listitem>
 297       <filename>/sys/bus/iio/iio:deviceX/sampling_frequency.
 298       </filename>
 299       </listitem>
 300       </itemizedlist>
 301       </para>
 302       <para>
 303       Here is how we can make use of the channel's indexing:
 304       <programlisting>
 305       static const struct iio_chan_spec light_channels[] = {
 306           {
 307               .type = IIO_VOLTAGE,
 308               .indexed = 1,
 309               .channel = 0,
 310               .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
 311           },
 312           {
 313               .type = IIO_VOLTAGE,
 314               .indexed = 1,
 315               .channel = 1,
 316               .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
 317           },
 318       }
 319       </programlisting>
 320       This will generate two separate attributes files for raw data
 321       retrieval:
 322       <itemizedlist>
 323       <listitem>
 324         <filename>/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw</filename>,
 325           representing voltage measurement for channel 0.
 326       </listitem>
 327       <listitem>
 328         <filename>/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw</filename>,
 329           representing voltage measurement for channel 1.
 330       </listitem>
 331       </itemizedlist>
 332       </para>
 333     </sect2>
 334   </sect1>
 335
 336   <sect1 id="iiobuffer"> <title> Industrial I/O buffers </title>
 337 !Finclude/linux/iio/buffer.h iio_buffer
 338 !Edrivers/iio/industrialio-buffer.c
 339
 340     <para>
 341     The Industrial I/O core offers a way for continuous data capture
 342     based on a trigger source. Multiple data channels can be read at once
 343     from <filename>/dev/iio:deviceX</filename> character device node,
 344     thus reducing the CPU load.
 345     </para>
 346
 347     <sect2 id="iiobuffersysfs">
 348     <title>IIO buffer sysfs interface </title>
 349     <para>
 350       An IIO buffer has an associated attributes directory under <filename>
 351       /sys/bus/iio/iio:deviceX/buffer/</filename>. Here are the existing
 352       attributes:
 353       <itemizedlist>
 354       <listitem>
 355       <emphasis>length</emphasis>, the total number of data samples
 356       (capacity) that can be stored by the buffer.
 357       </listitem>
 358       <listitem>
 359         <emphasis>enable</emphasis>, activate buffer capture.
 360       </listitem>
 361       </itemizedlist>
 362
 363     </para>
 364     </sect2>
 365     <sect2 id="iiobuffersetup"> <title> IIO buffer setup </title>
 366       <para>The meta information associated with a channel reading
 367         placed in a buffer is called a <emphasis> scan element </emphasis>.
 368         The important bits configuring scan elements are exposed to
 369         userspace applications via the <filename>
 370         /sys/bus/iio/iio:deviceX/scan_elements/</filename> directory. This
 371         file contains attributes of the following form:
 372       <itemizedlist>
 373       <listitem><emphasis>enable</emphasis>, used for enabling a channel.
 374         If and only if its attribute is non zero, then a triggered capture
 375         will contain data samples for this channel.
 376       </listitem>
 377       <listitem><emphasis>type</emphasis>, description of the scan element
 378         data storage within the buffer and hence the form in which it is
 379         read from user space. Format is <emphasis>
 380         [be|le]:[s|u]bits/storagebitsXrepeat[>>shift] </emphasis>.
 381         <itemizedlist>
 382         <listitem> <emphasis>be</emphasis> or <emphasis>le</emphasis>, specifies
 383           big or little endian.
 384         </listitem>
 385         <listitem>
 386         <emphasis>s </emphasis>or <emphasis>u</emphasis>, specifies if
 387           signed (2's complement) or unsigned.
 388         </listitem>
 389         <listitem><emphasis>bits</emphasis>, is the number of valid data
 390           bits.
 391         </listitem>
 392         <listitem><emphasis>storagebits</emphasis>, is the number of bits
 393           (after padding) that it occupies in the buffer.
 394         </listitem>
 395         <listitem>
 396         <emphasis>shift</emphasis>, if specified, is the shift that needs
 397           to be applied prior to masking out unused bits.
 398         </listitem>
 399         <listitem>
 400         <emphasis>repeat</emphasis>, specifies the number of bits/storagebits
 401         repetitions. When the repeat element is 0 or 1, then the repeat
 402         value is omitted.
 403         </listitem>
 404         </itemizedlist>
 405       </listitem>
 406       </itemizedlist>
 407       For example, a driver for a 3-axis accelerometer with 12 bit
 408       resolution where data is stored in two 8-bits registers as
 409       follows:
 410       <programlisting>
 411         7   6   5   4   3   2   1   0
 412       +---+---+---+---+---+---+---+---+
 413       |D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06)
 414       +---+---+---+---+---+---+---+---+
 415
 416         7   6   5   4   3   2   1   0
 417       +---+---+---+---+---+---+---+---+
 418       |D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07)
 419       +---+---+---+---+---+---+---+---+
 420       </programlisting>
 421
 422       will have the following scan element type for each axis:
 423       <programlisting>
 424       $ cat /sys/bus/iio/devices/iio:device0/scan_elements/in_accel_y_type
 425       le:s12/16>>4
 426       </programlisting>
 427       A user space application will interpret data samples read from the
 428       buffer as two byte little endian signed data, that needs a 4 bits
 429       right shift before masking out the 12 valid bits of data.
 430     </para>
 431     <para>
 432       For implementing buffer support a driver should initialize the following
 433       fields in <type>iio_chan_spec</type> definition:
 434       <programlisting>
 435           struct iio_chan_spec {
 436               /* other members */
 437               int scan_index
 438               struct {
 439                   char sign;
 440                   u8 realbits;
 441                   u8 storagebits;
 442                   u8 shift;
 443                   u8 repeat;
 444                   enum iio_endian endianness;
 445               } scan_type;
 446           };
 447       </programlisting>
 448       The driver implementing the accelerometer described above will
 449       have the following channel definition:
 450       <programlisting>
 451       struct struct iio_chan_spec accel_channels[] = {
 452           {
 453             .type = IIO_ACCEL,
 454             .modified = 1,
 455             .channel2 = IIO_MOD_X,
 456             /* other stuff here */
 457             .scan_index = 0,
 458             .scan_type = {
 459               .sign = 's',
 460               .realbits = 12,
 461               .storgebits = 16,
 462               .shift = 4,
 463               .endianness = IIO_LE,
 464             },
 465         }
 466         /* similar for Y (with channel2 = IIO_MOD_Y, scan_index = 1)
 467          * and Z (with channel2 = IIO_MOD_Z, scan_index = 2) axis
 468          */
 469     }
 470     </programlisting>
 471     </para>
 472     <para>
 473     Here <emphasis> scan_index </emphasis> defines the order in which
 474     the enabled channels are placed inside the buffer. Channels with a lower
 475     scan_index will be placed before channels with a higher index. Each
 476     channel needs to have a unique scan_index.
 477     </para>
 478     <para>
 479     Setting scan_index to -1 can be used to indicate that the specific
 480     channel does not support buffered capture. In this case no entries will
 481     be created for the channel in the scan_elements directory.
 482     </para>
 483     </sect2>
 484   </sect1>
 485
 486   <sect1 id="iiotrigger"> <title> Industrial I/O triggers  </title>
 487 !Finclude/linux/iio/trigger.h iio_trigger
 488 !Edrivers/iio/industrialio-trigger.c
 489     <para>
 490       In many situations it is useful for a driver to be able to
 491       capture data based on some external event (trigger) as opposed
 492       to periodically polling for data. An IIO trigger can be provided
 493       by a device driver that also has an IIO device based on hardware
 494       generated events (e.g. data ready or threshold exceeded) or
 495       provided by a separate driver from an independent interrupt
 496       source (e.g. GPIO line connected to some external system, timer
 497       interrupt or user space writing a specific file in sysfs). A
 498       trigger may initiate data capture for a number of sensors and
 499       also it may be completely unrelated to the sensor itself.
 500     </para>
 501
 502     <sect2 id="iiotrigsysfs"> <title> IIO trigger sysfs interface </title>
 503       There are two locations in sysfs related to triggers:
 504       <itemizedlist>
 505         <listitem><filename>/sys/bus/iio/devices/triggerY</filename>,
 506           this file is created once an IIO trigger is registered with
 507           the IIO core and corresponds to trigger with index Y. Because
 508           triggers can be very different depending on type there are few
 509           standard attributes that we can describe here:
 510           <itemizedlist>
 511             <listitem>
 512               <emphasis>name</emphasis>, trigger name that can be later
 513                 used for association with a device.
 514             </listitem>
 515             <listitem>
 516             <emphasis>sampling_frequency</emphasis>, some timer based
 517               triggers use this attribute to specify the frequency for
 518               trigger calls.
 519             </listitem>
 520           </itemizedlist>
 521         </listitem>
 522         <listitem>
 523           <filename>/sys/bus/iio/devices/iio:deviceX/trigger/</filename>, this
 524           directory is created once the device supports a triggered
 525           buffer. We can associate a trigger with our device by writing
 526           the trigger's name in the <filename>current_trigger</filename> file.
 527         </listitem>
 528       </itemizedlist>
 529     </sect2>
 530
 531     <sect2 id="iiotrigattr"> <title> IIO trigger setup</title>
 532
 533     <para>
 534       Let's see a simple example of how to setup a trigger to be used
 535       by a driver.
 536
 537       <programlisting>
 538       struct iio_trigger_ops trigger_ops = {
 539           .set_trigger_state = sample_trigger_state,
 540           .validate_device = sample_validate_device,
 541       }
 542
 543       struct iio_trigger *trig;
 544
 545       /* first, allocate memory for our trigger */
 546       trig = iio_trigger_alloc(dev, "trig-%s-%d", name, idx);
 547
 548       /* setup trigger operations field */
 549       trig->ops = &amp;trigger_ops;
 550
 551       /* now register the trigger with the IIO core */
 552       iio_trigger_register(trig);
 553       </programlisting>
 554     </para>
 555     </sect2>
 556
 557     <sect2 id="iiotrigsetup"> <title> IIO trigger ops</title>
 558 !Finclude/linux/iio/trigger.h iio_trigger_ops
 559      <para>
 560         Notice that a trigger has a set of operations attached:
 561         <itemizedlist>
 562         <listitem>
 563           <function>set_trigger_state</function>, switch the trigger on/off
 564           on demand.
 565         </listitem>
 566         <listitem>
 567           <function>validate_device</function>, function to validate the
 568           device when the current trigger gets changed.
 569         </listitem>
 570         </itemizedlist>
 571       </para>
 572     </sect2>
 573   </sect1>
 574   <sect1 id="iiotriggered_buffer">
 575     <title> Industrial I/O triggered buffers </title>
 576     <para>
 577     Now that we know what buffers and triggers are let's see how they
 578     work together.
 579     </para>
 580     <sect2 id="iiotrigbufsetup"> <title> IIO triggered buffer setup</title>
 581 !Edrivers/iio/industrialio-triggered-buffer.c
 582 !Finclude/linux/iio/iio.h iio_buffer_setup_ops
 583
 584
 585     <para>
 586     A typical triggered buffer setup looks like this:
 587     <programlisting>
 588     const struct iio_buffer_setup_ops sensor_buffer_setup_ops = {
 589       .preenable    = sensor_buffer_preenable,
 590       .postenable   = sensor_buffer_postenable,
 591       .postdisable  = sensor_buffer_postdisable,
 592       .predisable   = sensor_buffer_predisable,
 593     };
 594
 595     irqreturn_t sensor_iio_pollfunc(int irq, void *p)
 596     {
 597         pf->timestamp = iio_get_time_ns();
 598         return IRQ_WAKE_THREAD;
 599     }
 600
 601     irqreturn_t sensor_trigger_handler(int irq, void *p)
 602     {
 603         u16 buf[8];
 604         int i = 0;
 605
 606         /* read data for each active channel */
 607         for_each_set_bit(bit, active_scan_mask, masklength)
 608             buf[i++] = sensor_get_data(bit)
 609
 610         iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
 611
 612         iio_trigger_notify_done(trigger);
 613         return IRQ_HANDLED;
 614     }
 615
 616     /* setup triggered buffer, usually in probe function */
 617     iio_triggered_buffer_setup(indio_dev, sensor_iio_polfunc,
 618                                sensor_trigger_handler,
 619                                sensor_buffer_setup_ops);
 620     </programlisting>
 621     </para>
 622     The important things to notice here are:
 623     <itemizedlist>
 624     <listitem><function> iio_buffer_setup_ops</function>, the buffer setup
 625     functions to be called at predefined points in the buffer configuration
 626     sequence (e.g. before enable, after disable). If not specified, the
 627     IIO core uses the default <type>iio_triggered_buffer_setup_ops</type>.
 628     </listitem>
 629     <listitem><function>sensor_iio_pollfunc</function>, the function that
 630     will be used as top half of poll function. It should do as little
 631     processing as possible, because it runs in interrupt context. The most
 632     common operation is recording of the current timestamp and for this reason
 633     one can use the IIO core defined <function>iio_pollfunc_store_time
 634     </function> function.
 635     </listitem>
 636     <listitem><function>sensor_trigger_handler</function>, the function that
 637     will be used as bottom half of the poll function. This runs in the
 638     context of a kernel thread and all the processing takes place here.
 639     It usually reads data from the device and stores it in the internal
 640     buffer together with the timestamp recorded in the top half.
 641     </listitem>
 642     </itemizedlist>
 643     </sect2>
 644   </sect1>
 645   </chapter>
 646   <chapter id='iioresources'>
 647     <title> Resources </title>
 648       IIO core may change during time so the best documentation to read is the
 649       source code. There are several locations where you should look:
 650       <itemizedlist>
 651         <listitem>
 652           <filename>drivers/iio/</filename>, contains the IIO core plus
 653           and directories for each sensor type (e.g. accel, magnetometer,
 654           etc.)
 655         </listitem>
 656         <listitem>
 657           <filename>include/linux/iio/</filename>, contains the header
 658           files, nice to read for the internal kernel interfaces.
 659         </listitem>
 660         <listitem>
 661         <filename>include/uapi/linux/iio/</filename>, contains files to be
 662           used by user space applications.
 663         </listitem>
 664         <listitem>
 665          <filename>tools/iio/</filename>, contains tools for rapidly
 666           testing buffers, events and device creation.
 667         </listitem>
 668         <listitem>
 669           <filename>drivers/staging/iio/</filename>, contains code for some
 670           drivers or experimental features that are not yet mature enough
 671           to be moved out.
 672         </listitem>
 673       </itemizedlist>
 674     <para>
 675     Besides the code, there are some good online documentation sources:
 676     <itemizedlist>
 677     <listitem>
 678       <ulink url="http://marc.info/?l=linux-iio"> Industrial I/O mailing
 679       list </ulink>
 680     </listitem>
 681     <listitem>
 682       <ulink url="http://wiki.analog.com/software/linux/docs/iio/iio">
 683       Analog Device IIO wiki page </ulink>
 684     </listitem>
 685     <listitem>
 686       <ulink url="https://fosdem.org/2015/schedule/event/iiosdr/">
 687       Using the Linux IIO framework for SDR, Lars-Peter Clausen's
 688       presentation at FOSDEM </ulink>
 689     </listitem>
 690     </itemizedlist>
 691     </para>
 692   </chapter>
 693 </book>
 694
 695 <!--
 696 vim: softtabstop=2:shiftwidth=2:expandtab:textwidth=72
 697 -->