(Partially) graduating IIO

The industrial I/O (IIO) subsystem has lived in the staging tree for some time. It provides a framework for drivers that deal with all kinds of sensors that measure quantities like voltages, temperatures, acceleration, ambient light, and more. There has been some disagreement over the years about how sensors of this type should fit into the kernel; IIO, it is hoped, will provide the answer.

The core IIO code sat out of tree for a long time; the state of the code, it is said, reflected that fact. There has been a determined effort to improve things in the staging tree, with some measurable results. There is now a set of core IIO patches that, according to maintainer Jonathan Cameron, is now ready to move out of staging and into the mainline proper.

IIO sensors vary a lot, from simple, low-bandwidth sensors to complex, high-bandwidth devices. The initial IIO move is aimed at the first set. For this kind of sensor, the user-space interface is expected to live entirely in sysfs, under /sys/bus/iio/devices. Each device entry will have a number of attributes; some, like name and sampling_frequency, will be present for all sensors. Others will depend on what the sensor actually measures; the proposed ABI attempts to standardize the names of those attributes wherever possible.

The plan is to get this core interface into the mainline, then to start moving the simpler (and cleaner) drivers after it. Support for more complex devices will come later. As of this writing, this code has not been pulled for 3.2, but that could yet happen. Meanwhile, vast numbers of IIO changes have gone into the staging tree for 3.2; there is clearly a lot of interest in getting this subsystem into shape.

Index entries for this article
Kernel	Device drivers/Industrial I/O
Kernel	Industrial I/O devices

---

to post comments

(Partially) graduating IIO - not aiming for 3.2

Posted Nov 3, 2011 10:37 UTC (Thu) by jic23 (subscriber, #56049) [Link]

Thanks for the write up! Just to clarify one point, I was never proposing a 3.2 merge. The intent is definitely 3.3 as the core part hasn't yet garnered anywhere near enough review. Basically we got it into shape a few weeks too late and people have been busy.

The other big issue (possibly blocker) that has been raised is the need for in kernel interfaces. This is particularly of interest to the SoC world, where one ADC (with a multiplexer) can be used for hwmon, touchscreen (or other input) and general purpose (proposed IIO userspace user-space abi). There are two types of such interface, pull and push. There are patches for supporting both but the interaction between the two gets 'interesting'.

http://marc.info/?l=linux-iio&m=132016705319258&w=2

It's not that the in kernel interface issue directly effects the core code as proposed, but rather that we need to show that it fits well with what is in this first step (e.g. it needs to be up and running in the staging code). Always easier to answer, a 'can you do this' question if you can say 'look we did it here'!

Just to finish with the age old call for help... Anyone interested in this area, please review the code. Ideally start with the core series Jon links to and if anyone has lots of time, please join in on linux-iio@vger.kernel.org where all the 'nasty' stuff goes first.

Thanks again for the write up.

Jonathan Cameron

(Partially) graduating IIO

Posted Nov 9, 2011 17:14 UTC (Wed) by samroberts (subscriber, #46749) [Link]

What's the relationship between comedi and IIO? They both seem to do much the same thing.