RFC: Merge strategy for Industrial I/O (staging?)

RFC: Merge strategy for Industrial I/O (staging?)

[Jonathan Cameron]

Dear All,

IIO is intended to be a subsystem for sensors such as ADCs, accelerometers,
gyros, light sensors and others that have reasonably high update rates and
typically are connected via i2c or spi busses.

The latest patch set posted to lkml was v4
http://thread.gmane.org/gmane.linux.kernel/860693
Tree at 
http://git.kernel.org/?p=linux/kernel/git/jic23/iio_v4.git;a=summary

original discussion of the need for such a subsystem:
http://lkml.org/lkml/2008/5/20/135

The last couple of versions of IIO have recieved some useful feedback from
a number of people, and feedback from various users has led to a number
of recent bug fixes.  Unfortunately, full reviews of any given element have
not be forthcoming.  Several people who have in principle offered to help
haven't had the time as yet.

In the short term, the lack of review of the core (patch 1 of the above set)
leads to a stack of device drivers sitting in the git repository waiting on
the core being merged. Currently in the tree there are 3 acceleromters, an
adc and a light sensor.  I also have an IMU driver (ADIS16350 family) that
needs a little more cleaning up and testing with latest IIO core.

Increasing numbers of drivers that would fall within the scope of IIO are
being submitted to various other subsystems (hwmon for example) and getting
bounced out as inappropriate for that subsystem.  So, whilst I'd be reasonably
happy to maintain the subsystem out of kernel until interest in the devices
covered grows, or people have time to assist, I was wondering whether it
would be appropriate to submit the subsystem and the associated driver
set to staging.

Whilst some elements could definitely do with more work (for example the
use of rtc's to get periodic timers, is clunky at best), much of the core
and the actual device drivers are to my mind pretty clean.  So the question
is, 'Is lack of reviewers a valid reason to submit to staging in the meantime?'

What do people think?

All offers of review or other suggestions on how to proceed also welcome!

Also I'm still not that keen on the name if anyone has a better idea.

Thanks

Jonathan

Re: RFC: Merge strategy for Industrial I/O (staging?)

[Greg KH]

On Wed, Aug 12, 2009 at 09:27:05AM +0000, Jonathan Cameron wrote:
> Dear All,
> 
> IIO is intended to be a subsystem for sensors such as ADCs, accelerometers,
> gyros, light sensors and others that have reasonably high update rates and
> typically are connected via i2c or spi busses.
> 
> The latest patch set posted to lkml was v4
> http://thread.gmane.org/gmane.linux.kernel/860693
> Tree at 
> http://git.kernel.org/?p=linux/kernel/git/jic23/iio_v4.git;a=summary
> 
> original discussion of the need for such a subsystem:
> http://lkml.org/lkml/2008/5/20/135
> 
> The last couple of versions of IIO have recieved some useful feedback from
> a number of people, and feedback from various users has led to a number
> of recent bug fixes.  Unfortunately, full reviews of any given element have
> not be forthcoming.  Several people who have in principle offered to help
> haven't had the time as yet.
> 
> In the short term, the lack of review of the core (patch 1 of the above set)
> leads to a stack of device drivers sitting in the git repository waiting on
> the core being merged. Currently in the tree there are 3 acceleromters, an
> adc and a light sensor.  I also have an IMU driver (ADIS16350 family) that
> needs a little more cleaning up and testing with latest IIO core.
> 
> Increasing numbers of drivers that would fall within the scope of IIO are
> being submitted to various other subsystems (hwmon for example) and getting
> bounced out as inappropriate for that subsystem.  So, whilst I'd be reasonably
> happy to maintain the subsystem out of kernel until interest in the devices
> covered grows, or people have time to assist, I was wondering whether it
> would be appropriate to submit the subsystem and the associated driver
> set to staging.
> 
> Whilst some elements could definitely do with more work (for example the
> use of rtc's to get periodic timers, is clunky at best), much of the core
> and the actual device drivers are to my mind pretty clean.  So the question
> is, 'Is lack of reviewers a valid reason to submit to staging in the meantime?'

Yes, I have no objection to taking these patches in staging for now, as
long as you submit it with a TODO list of things left to be done to get
it merged to the main portion of the kernel tree.

So, send me the patches!

thanks,

greg k-h

Re: RFC: Merge strategy for Industrial I/O (staging?)

[Jonathan Cameron]

Greg KH wrote:
> On Wed, Aug 12, 2009 at 09:27:05AM +0000, Jonathan Cameron wrote:
>> Dear All,
>>
>> IIO is intended to be a subsystem for sensors such as ADCs, accelerometers,
>> gyros, light sensors and others that have reasonably high update rates and
>> typically are connected via i2c or spi busses.
>>
>> The latest patch set posted to lkml was v4
>> http://thread.gmane.org/gmane.linux.kernel/860693
>> Tree at 
>> http://git.kernel.org/?p=linux/kernel/git/jic23/iio_v4.git;a=summary
>>
>> original discussion of the need for such a subsystem:
>> http://lkml.org/lkml/2008/5/20/135
>>
>> The last couple of versions of IIO have recieved some useful feedback from
>> a number of people, and feedback from various users has led to a number
>> of recent bug fixes.  Unfortunately, full reviews of any given element have
>> not be forthcoming.  Several people who have in principle offered to help
>> haven't had the time as yet.
>>
>> In the short term, the lack of review of the core (patch 1 of the above set)
>> leads to a stack of device drivers sitting in the git repository waiting on
>> the core being merged. Currently in the tree there are 3 accelerometers, an
>> adc and a light sensor.  I also have an IMU driver (ADIS16350 family) that
>> needs a little more cleaning up and testing with latest IIO core.
>>
>> Increasing numbers of drivers that would fall within the scope of IIO are
>> being submitted to various other subsystems (hwmon for example) and getting
>> bounced out as inappropriate for that subsystem.  So, whilst I'd be reasonably
>> happy to maintain the subsystem out of kernel until interest in the devices
>> covered grows, or people have time to assist, I was wondering whether it
>> would be appropriate to submit the subsystem and the associated driver
>> set to staging.
>>
>> Whilst some elements could definitely do with more work (for example the
>> use of rtc's to get periodic timers, is clunky at best), much of the core
>> and the actual device drivers are to my mind pretty clean.  So the question
>> is, 'Is lack of reviewers a valid reason to submit to staging in the meantime?'
> 
> Yes, I have no objection to taking these patches in staging for now, as
> long as you submit it with a TODO list of things left to be done to get
> it merged to the main portion of the kernel tree.
> 
> So, send me the patches!
Will do, thanks.

Jonathan

Re: RFC: Merge strategy for Industrial I/O (staging?)

[Robert Schwebel]

Hi Jonathan,

On Wed, Aug 12, 2009 at 09:27:05AM +0000, Jonathan Cameron wrote:
> The last couple of versions of IIO have recieved some useful feedback
> from a number of people, and feedback from various users has led to a
> number of recent bug fixes. Unfortunately, full reviews of any given
> element have not be forthcoming. Several people who have in principle
> offered to help haven't had the time as yet.

Uuuh, sorry, same here. Wanted to check your code and docs for quite
some time now. So I'll try to at least give you a brain dump on that
topic here.

A driver framework for industrial I/O would be quite welcome; we
constantly see a need for something like that in our automation &
control projects. However, I see some requirements which are currently
not fully addressed by your code.

I'll try to outline the requirements (as I see them) below:

- "process variables" contain the actual data (voltage, temperature etc)
  from the in/outputs. However, process variables need some additional
  meta data to be attached to them, like min/max, unit, scale etc. This
  could be done in userspace, but some cards can provide that
  information directly from the hardware.

- The memory layout of process data is dictated by the transportation
  model. Most modern industrial I/O systems are not based on single-
  channel local I/Os, but on fieldbus I/Os. So for example, if we
  get an EtherCAT frame, we want to push the whole frame into memory
  by DMA, without copying the actual data any more. Let's say that
  several process variables in a block of memory are a "transportation
  unit".

  All these "simple" I/O sources like I2C or SPI based ADCs,
  acceleration devices etc. are just a simplified case of the above.
  For example, acceleration devices often have a three-register process
  data block which contains the three accel values, and the
  transportation unit could be the SPI transfer.

  Events may happen when transportation units arrive; either because
  the hardware does it automatically (i.e. Hilscher CIF(x) cards can
  trigger an interrupt if they have done their bus cycles), or by
  an artificial software event (i.e. in Modbus/TCP you have to decide
  about the "cycle" in software, simply because there is no cycle).

- Applications need to access the process data asynchronously. As
  process data will come from several sources, it can not be expected
  that there is any synchronisation mechanism. So how to synchronize
  the data? I assume some kind of RCU mechanism would be great. For
  each Transportation Unit, there is one producer (the driver) and
  many consumers (the applications). New data which comes in from
  the data source will superseed old data, but for applications
  which didn't finish their cycle yet, the old data needs to stay
  consistent (with all meta data, min/max etc).

  However, I'm not sure if the RCU based process image handling
  should be done in kernel or user space. From the code management view,
  it would be great to have an infrastructure in the kernel.
  Technically, I'm not sure.

  Is something like RCU protected objects in a shared memory space
  possible between kernel and userspace?

- Synchronisation on the application level is coupled to the I/O layer.
  For example, in CANopen networks you have a "sync" message. In Sercos
  III you have the network cycle (MTs/ATs). These may want to trigger an
  application cycle (i.e. PLC cycle) which needs access to the data. So
  what we need is a possibility to let userspace apps sleep until the
  process data layer triggers an event (netlink?).

- We need persistence in the framework. PLCs have the requirement to be
  power-fail safe. Let's assume you have a transportation belt and get
  information about the position of a "thing" on the belt, then the
  power fails and comes back (box boots), you want to continue with the
  old position of the "thing". So the process data backing store
  must be able to live for example on a battery backed SRAM, and all
  transactions need to be atomic.

- Process data access has realtime requirements, but only during an
  "operational" state of an application data block. A usual pattern is
  that, while being in non-operational mode, an application does some
  preparation work, like mapping it's process data, initializing
  things etc. Then it enters operational-mode. During that phase,
  hard realtime conditions may have to be fulfilled. So no memory
  allocation is allowed, mlockall(), priorities must be taken care of
  etc.

- The application "blocks" probably want to live in userspace, but the
  layer that provides the process data should be the kernel.

So in conclusion, I think that before discussing the I/O layer we need
to address the process data handling first. If we start with the
drivers, it won't be possible to add features like persistence any more.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: RFC: Merge strategy for Industrial I/O (staging?)

[Jonathan Cameron]

Robert Schwebel wrote:
> Hi Jonathan,
> 
> On Wed, Aug 12, 2009 at 09:27:05AM +0000, Jonathan Cameron wrote:
>> The last couple of versions of IIO have recieved some useful feedback
>> from a number of people, and feedback from various users has led to a
>> number of recent bug fixes. Unfortunately, full reviews of any given
>> element have not be forthcoming. Several people who have in principle
>> offered to help haven't had the time as yet.
> 
> Uuuh, sorry, same here. Wanted to check your code and docs for quite
> some time now. 
Not to worry, there are always far too many things to do in the day!
> So I'll try to at least give you a brain dump on that
> topic here.
> 
> A driver framework for industrial I/O would be quite welcome; we
> constantly see a need for something like that in our automation &
> control projects. However, I see some requirements which are currently
> not fully addressed by your code.
> 
> I'll try to outline the requirements (as I see them) below:
> 
> - "process variables" contain the actual data (voltage, temperature etc)
>   from the in/outputs. However, process variables need some additional
>   meta data to be attached to them, like min/max, unit, scale etc. This
>   could be done in userspace, but some cards can provide that
>   information directly from the hardware.
I definitely agree this sort of info is useful.  Even in cases where the chip
doesn't directly provide it, a given driver often covers multiple chips
with say different accelerations ranges. It is useful to have everything needed
to use the data exported to userspace.  In the case of ring buffers, the data
may even be unprocessed and not aligned in a simple fashion. Similar variables
could be used to tell userspace that the data coming out is 10 bits shifted 2
within a 16 bit field. Personally I favor exporting this sort of thing under
standard names in sysfs rather than the alternative of creating any sort
of HAL type record.  Makes it easy to retrofit these only where needed.  If there
is no shift or a parameter we don't have info on, then there is nothing under
the relevant name in sysfs.  A suitable userspace library then does any mangling
transparently.

> 
> - The memory layout of process data is dictated by the transportation
>   model. Most modern industrial I/O systems are not based on single-
>   channel local I/Os, but on fieldbus I/Os. 
> So for example, if we
>   get an EtherCAT frame, we want to push the whole frame into memory
>   by DMA, without copying the actual data any more. Let's say that
>   several process variables in a block of memory are a "transportation
>   unit".
I feel we need to be a little careful with not over extending the scope of
a given subsystem.  I'm not familiar with fieldbus (being mostly interested
in embedded sensors directly connected to a linux running device)
so my understanding bares a startling resemblance to the wikipedia page.

Given the example above, you probably want a zero copy solution (which IIO
gets no where near at the momentm vu) I'd imagine best bet is to shift the frame
directly into userspace and do all your processing here. (however this is
well out of my experience, so I could be completely wrong!)
> 
>   All these "simple" I/O sources like I2C or SPI based ADCs,
>   acceleration devices etc. are just a simplified case of the above.
>   For example, acceleration devices often have a three-register process
>   data block which contains the three accel values, and the
>   transportation unit could be the SPI transfer.
That seems reasonable though we are talking whole different levels of
complexity.
> 
>   Events may happen when transportation units arrive; either because
>   the hardware does it automatically (i.e. Hilscher CIF(x) cards can
>   trigger an interrupt if they have done their bus cycles), or by
>   an artificial software event (i.e. in Modbus/TCP you have to decide
>   about the "cycle" in software, simply because there is no cycle).

> - Applications need to access the process data asynchronously. As
>   process data will come from several sources, it can not be expected
>   that there is any synchronisation mechanism. So how to synchronize
>   the data? I assume some kind of RCU mechanism would be great. For
>   each Transportation Unit, there is one producer (the driver) and
>   many consumers (the applications). New data which comes in from
>   the data source will superseed old data, but for applications
>   which didn't finish their cycle yet, the old data needs to stay
>   consistent (with all meta data, min/max etc).
Makes sense.  Though I'd imagine there are also cases where you don't want
to always replace data, so things might need to be more complex.
> 
>   However, I'm not sure if the RCU based process image handling
>   should be done in kernel or user space. From the code management view,
>   it would be great to have an infrastructure in the kernel.
>   Technically, I'm not sure.
> 
>   Is something like RCU protected objects in a shared memory space
>   possible between kernel and userspace?
> 
> - Synchronisation on the application level is coupled to the I/O layer.
>   For example, in CANopen networks you have a "sync" message. In Sercos
>   III you have the network cycle (MTs/ATs). These may want to trigger an
>   application cycle (i.e. PLC cycle) which needs access to the data. So
>   what we need is a possibility to let userspace apps sleep until the
>   process data layer triggers an event (netlink?).
Netlink would work, or a simple chardev (like input or indeed IIO use)
> 
> - We need persistence in the framework. PLCs have the requirement to be
>   power-fail safe. Let's assume you have a transportation belt and get
>   information about the position of a "thing" on the belt, then the
>   power fails and comes back (box boots), you want to continue with the
>   old position of the "thing". So the process data backing store
>   must be able to live for example on a battery backed SRAM, and all
>   transactions need to be atomic.
This sort of requirement does suggest to me that you want to do as much
as possible in userspace where things like backing stores would be much
easier to implement in a hardware agnostic way.

> 
> - Process data access has realtime requirements, but only during an
>   "operational" state of an application data block. A usual pattern is
>   that, while being in non-operational mode, an application does some
>   preparation work, like mapping it's process data, initializing
>   things etc. Then it enters operational-mode. During that phase,
>   hard realtime conditions may have to be fulfilled. So no memory
>   allocation is allowed, mlockall(), priorities must be taken care of
>   etc.
That shouldn't be too much of a problem as you can always preallcoate
a large memory pool to cover any eventualities as I'd imagine you can
work out the worst cases in advance.
 
> - The application "blocks" probably want to live in userspace, but the
>   layer that provides the process data should be the kernel.
> 
> So in conclusion, I think that before discussing the I/O layer we need
> to address the process data handling first. If we start with the
> drivers, it won't be possible to add features like persistence any more.
You have an interesting situation, but I'm not sure it corresponds terribly
closely to what IIO is currently aimed at.  The complexity that you describe
would be a complete nightmare on a relatively light weight device if you don't 
actually need it. Ironically the name would be much more suitable for your
application requirements that mine!

To get more feedback I'd suggest reposting your requirements to LKML in a
separate thread with a specific title.  I suspect not many relevant
people will come across them in this one! (please cc me.)
Even if optimum approaches are different, as you've identified there are
elements that overlap between the usecases.

Thanks,

Jonathan