[lm-sensors] [Industrial I/O] [0/13] RFC: IIO v3 patchset
jic23 at cam.ac.uk
Tue Dec 2 14:43:37 CET 2008
>> have both functions. The sort of devices we are talking typically
>> communicate over I2C or SPI buses though drivers for rs232 devices etc are
>> definitely on the cards. Basically we are interested in devices where direct
>> memory mapped access is not possible.
> We have I2C and SPI drivers so I assume you will use the lower layers of
> the stacks to do this ?
Yes, in much the same way that for example hwmon is built on top of these
(amongst other interfaces)
>> For discussion of why these don't fit within existing subsystems see
>> http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread.
> I don't see much there which says why you can't unify all this in a user
> space library.
Indeed, that was an option considered at the time and the majority of that
discussion focused on how to do things in a similar way to existing similar
Perhaps this question needs further clarification.
Much of the stuff provided in this initial patch set could indeed be provided
by a fairly complex user space library.
I get the feeling this rest of this response is going to look pretty familiar.
Though as I have never attempted to code anything other than simple userspace
drivers I suspect others may have more detailed responses. These are in no
I believe the principle argument in favour of user space drivers is that of
enhanced stability as they are unlikely to be able to bring the kernel down.
This advantage is indeed valid here.
The other advantage is that the number of copies required to get data to and
from hardware are reduced. For the devices considered here a userspace driver
would have to go via one of the chrdev interfaces and neither i2c-dev or
spidev are able to support mmap ed interfaces.
The problems I can forsee (or have encountered) with user space drivers
for this sort of device:
* In many cases the ADCs form part of more complex devices which already
have a support within the kernel. (e.g. PMICs such as those supported
by the DA903x mfd driver) and as such any additional interface will
require at least some kernel parts. Other places I've seen ADCs that
I'd like to have available via a consistent interface, include firewire
and usb cameras (aux ADC's and DAC's are common for controlling pan
tilt heads etc). Some of these could be implemented in userspace (and
quite possibly should be,) but others would require driver changes that
will effectively equal those of adding direct support for the subsystem
described in these patches.
* Spidev and i2cdev are fairly restricted interfaces which I have used
extensively for initial investigation of sensors. The key thing here
is that almost no devices use purely these interfaces. They include
interrupt lines etc requiring relatively complex handlers. Thus any
driver would probably require at least some kernel space element per
chip anyway. Also worth noting that this tends to be the most complex
and hence probably error prone part of these drivers. The spidev
documentation talks about the limitations of the driver.
An example of the problems that would be encountered with the current i2c-dev
implementation within a full driver would be a control register read
on a VTI SCA3000 (i2c) accelerometer. This would require an initial 3 byte
write followed by a 1 byte read. In kernel space this whole thing
can be set up in a dma capable buffer and done in one go with copies out
to userspace only needed if the value is meant to be read by the user.
* Need to provide kernel space interfaces. This actually fulls under the RFC
question of what the scope of this subsystem should be. For example,
things like battery chargers, free fall detectors etc frequently use
generic components of the types that IIO will include. The systems that
use these sometimes require kernel level access which a userspace driver
clearly cannot supply.
* Performance: Thinks like time stamping of data ready signals needs to be
as near as possible to the source interrupt. As for the complex question
of which is optimal for the ring buffering functionality, this would need
thorough optimization of both approaches before it could be addressed.
I'm not aware of any similar comparisons but would be grateful if anyone
could direct me to any they know of. It is also worth noting here that many
applications that will use the ring buffered interface will never actually
read the contents of the buffer as they are interested in only restricted
regions of data (based on some external trigger).
In conclusion, I'd be interested in the long run in the possibility of
moving all the above functionality into userspace but at the moment don't
believe it to be the sensible option here.
The alternative of would be to provide only those drivers that would
benefit from a kernel space driver within this subsystem.
This would lose the advantages to be gained from a consistent interface.
This could in turn be made transparent via a userspace library but only
at the cost of unnecessary complexity.
> For RS232/423/.. devices you can go this path if you want (but I would
> keep it all in userspace anyway) as you can use a line discipline to sit
> on top of the port and provide another interface (eg the way PPP does)
An interesting suggestion. The main reason I'd be interested in bringing
these into the kernel is to do with the handling of additional interrupt
lines (which a number of similar devices have).
Thanks for the comments,
More information about the lm-sensors