As I’ve said in the introductory article about IIO, a subject worth talking about are triggered buffers.
So first let’s see how triggers are used in the IIO Subsystem. A specific trigger can be associated to an IIO device by registering it and set it in
iio_device->trig. Also there is the possibility to use a generic trigger for different IIO devices and in this case it should be declared as a separate module.
Let’s have a look at the API the kernel exposes for IIO triggers. To allocate a trigger we should do something like this:
struct iio_trigger *trig = iio_allocate_trigger("foo");
An important field of this structure is
.ops. This is a
struct iio_trigger_ops and represents the
operations structure for an iio_trigger. The key elements to fill here are
.set_triggered_state, function used to switch on/off the trigger on demand. Having all these set, we can then register the trigger using
Currently triggers are only used in IIO to fill software buffers. Any device supporting
INDIO_BUFFER_TRIGGERED has the consumer interface automatically created.
iio_dev structure has a field name
.pollfunc, which represents the function triggered at each conversion. Its purpose is to retrieve data from the device and feed them into the buffer. So buffers and triggers are very connected in the IIO Subsystem.
There are two kind of buffers in IIO:
A set of IIO helper functions to set up triggered buffers can be found in
drivers/iio/industrialio-triggered-buffer.c. An important function here is
iio_triggered_buffer_setup, which will allocate the buffer and the pollfunc, as well as register the buffer with the IIO core.
An example of driver which uses triggered buffers is kxcj-1013. The code that actually does the settings is:
ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time, kxcjk1013_trigger_handler, NULL);
A next post about IIO events will come soon and remember, for additional information: