81 lines
3 KiB
ReStructuredText
Executable file
81 lines
3 KiB
ReStructuredText
Executable file
========
|
|
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_free` — Resource-managed iio_trigger_free
|
|
* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
|
|
* :c:func:`devm_iio_trigger_unregister` — Resource-managed
|
|
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:
|