My work lately

Remember the post introducing my new toys, ISL29035 light sensor and DLN-2 adapter? After I got familiar with the hardware and the isl29018 driver, I started working a little on the code.

One of the obvious problems is this driver uses some non-standard sysfs attributes, such as range, range_available, adc_resolution, adc_resolution_available.

In order to fix this I did a set of patches which introduces IIO_CHAN_INFO_RANGE and then refactors isl29018 driver code in order to use standard attributes. Besides this, it also renames lux_scale to calibscale and lux_uscale to ucalibscale to avoid any confusion since these parameters are used for hardware applied calibration.

The purpose of these patches is to change the isl29018 driver to use
standard IIO attributes in order to be moved out of staging.

Besides this, I also worked on a patchset moving iio userspace applications (iio_event_monitor, generic_buffer, lsiio) out of staging. This kind of applications should stay in tools/ directory (for our case in tools/iio/). As part of this patchset, I also worked on iio_utils.h file which had a lot of inline functions, containing a lot of code and that isn’t nice at all. To fix this, I did a patch introducing iio_utils.c and moved all the implementation here.

I’m now waiting for Jonathan to review my patches and hopefully then I can continue with my plan of getting isl29018 driver out of staging.


IIO triggered buffers

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 .owner (usually THIS_MODULE) and .set_triggered_state, function used to switch on/off the trigger on demand. Having all these set, we can then register the trigger using iio_trigger_register.

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,

To see how the kxcjk1013_trigger_handler is implemented you can have a look here.

A next post about IIO events will come soon and remember, for additional information: