Re: Kernel driver with multiple SPI sources

[Ben Nizette <bn@niasdigital.com>]

On Fri, 2009-10-16 at 21:50 +1300, Bertrand Roussel wrote:

>  _____      ______
> |     | <> |  ADC |
> |     |    |______|
> | IMU |     ______  <> Bus SPI
> |     | <> |  MAG |
> |_____|    |______|
> 
> Each block correspond to a driver:
> * IMU is a basic char driver, depending on both ADC and MAG driver,
> and that register new spi_device to the spi_master
> * ADC and MAG are instances of an spi_driver, with a char driver as an interface
> 

Why is the IMU part a kernel driver?  Surely the kernel only needs to
know about the ADC and the MAG unit, expose interfaces for them to the
outside world and have all the IMU maths in userspace?

The ADC and MAG drivers there fit exactly in to the model of the new IIO
subsystem (industrial I/O).  This subsystem is in staging/ at the moment
rather than being a first-class citizen but don't let that stop you
using it.  IIO gives each device registered through it a number of sysfs
knobs to control things like sample rate etc and then a time-stamped
ring buffer holding the actual data.  Your IMU then just sits in
userspace consuming that buffer, matching ADC and MAG entries with the
same (similar) timestamps and doing the maths.

And no, you certainly should not spin-wait on the data to become
available.  Just set up an interrupt handler for the pin change, from
the interrupt start an spi_async transfer or spawn a workqueue to get
the data out.  The async callback or workqueue then can submit the data
to IIO for buffering for userspace.

	--Ben.