summaryrefslogtreecommitdiffstats
path: root/Documentation/driver-api/iio/triggers.rst
blob: dfd7ba3eabde0244b2d1895a24cb16fa052b8eb3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
========
Triggers
========

* struct :c:type:`iio_trigger` — industrial I/O trigger device
* :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc
* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
  iio_trigger_unregister
* :c:func:`iio_trigger_validate_own_device` — Check if a trigger and IIO
  device belong to the same device

In many situations it is useful for a driver to be able to capture data based
on some external event (trigger) as opposed to periodically polling for data.
An IIO trigger can be provided by a device driver that also has an IIO device
based on hardware generated events (e.g. data ready or threshold exceeded) or
provided by a separate driver from an independent interrupt source (e.g. GPIO
line connected to some external system, timer interrupt or user space writing
a specific file in sysfs). A trigger may initiate data capture for a number of
sensors and also it may be completely unrelated to the sensor itself.

IIO trigger sysfs interface
===========================

There are two locations in sysfs related to triggers:

* :file:`/sys/bus/iio/devices/trigger{Y}/*`, this file is created once an
  IIO trigger is registered with the IIO core and corresponds to trigger
  with index Y.
  Because triggers can be very different depending on type there are few
  standard attributes that we can describe here:

  * :file:`name`, trigger name that can be later used for association with a
    device.
  * :file:`sampling_frequency`, some timer based triggers use this attribute to
    specify the frequency for trigger calls.

* :file:`/sys/bus/iio/devices/iio:device{X}/trigger/*`, this directory is
  created once the device supports a triggered buffer. We can associate a
  trigger with our device by writing the trigger's name in the
  :file:`current_trigger` file.

IIO trigger setup
=================

Let's see a simple example of how to setup a trigger to be used by a driver::

      struct iio_trigger_ops trigger_ops = {
          .set_trigger_state = sample_trigger_state,
          .validate_device = sample_validate_device,
      }

      struct iio_trigger *trig;

      /* first, allocate memory for our trigger */
      trig = iio_trigger_alloc(dev, "trig-%s-%d", name, idx);

      /* setup trigger operations field */
      trig->ops = &trigger_ops;

      /* now register the trigger with the IIO core */
      iio_trigger_register(trig);

IIO trigger ops
===============

* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger.

Notice that a trigger has a set of operations attached:

* :file:`set_trigger_state`, switch the trigger on/off on demand.
* :file:`validate_device`, function to validate the device when the current
  trigger gets changed.

More details
============
.. kernel-doc:: include/linux/iio/trigger.h
.. kernel-doc:: drivers/iio/industrialio-trigger.c
   :export: