ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Jonathan Cameron]

Hi All,

I'm posting this reply to linux-iio as it may cut down on the amount of
repeated discussion and allow us to draw everyone relevant together.
Please CC anyone relevant (I've just added Greg and Lars-Peter as they
commented on the ZIO RFC and hence are probably at least vaguely
interested.)

Federico asked me to comment on the zio wiki page analysing IIO a week
or so ago.  I didn't get round to it until yesterday (was prompted to
take the time to do it by their posting of the patch series).

Anyhow, my points below are intended more for discussion than anything
else.  There are clearly things we can learn from each other and I
suspect at some point the question of whether we can merge (or at least
share some infrastructure) will come up so it is worth keeping that in
mind as we go. Targets are different but there will clearly be a blurred
region between the two!  There are strengths and weaknesses to both
approaches so lets work out what they are and make sure we agree the facts.

Jonathan

> Hello Mr Cameron,
> 
> I'm working on a new linux framework for data acquisition systems, ZIO.
> The open hardware repository (http://www.ohwr.org/) hosts the ZIO
> project at http://www.ohwr.org/projects/zio/.
> 
> Before starting with this project I analyzed both COMEDI and IIO to
> undestand if they comply with our requirements, and they don't. I'm glad
> if you can read my analysis about IIO on the wiki page of the ZIO project,
> and give me your opinion. There is not much documentation about IIO, so I
> read the entire code to understand how it works; maybe I misunderstood
> something and you can correct me where I'm wrong in my analysis.
> Bear in mind that our main case are boards with mega-samples for second
> and with a time-stamp precision of sub-nanoseconds. Data output is as
> important as data input and we don't handle small sets of samples.
> 
> I think that IIO is a good work (absolutely better the COMEDI) but it
> doesn't meet with our requirements and is directed toward a different
> target (small chips). The first time, I analyzed the IIO version within kernel
> 2.6.38/39 and I really appreciate the improvements done about sysfs
> centralization and channel organization, but there are some points
> where I still disagree.
> 
> The ZIO project is under development at this time, but we think that
> we'll submit a patch in one or two weeks based on the linux next tree;
> Greg K.H. suggests us to write also on the IIO mailing list when the ZIO
> patch is submitted.
> 
> PS: English is not my native language, so ... I'm sorry.
Would you mind if I posted this to linux-iio as well?  It might save us
all some time.  (If you don't mind and want to reply, then just cc the list)

Sorry I didn't get to this earlier. Things have been a bit manic for the
last few weeks.

Anyhow, overview of IIO is mostly fair and accurate. Few minor comments
though (particularly as you've now posted and received the predictable
questions!)  Note some of these refer to changes we could make,
obviously your consideration is based on what is there so they don't
directly apply to the web page.

1) Number of devices is currently limited at 256 entirely because it is
considered rude to request many more devices than you actually expect to
see.  Can up this the moment someone actually says they have a reason to
do so.

2) Output signal support is patchy and currently unbuffered, but there
is some.  Agreed it is rubbish.  Analog Devices were putting some effort
in on this front, but  I don't know what stage it reached.
It wasn't of interest to me so wasn't in the early code.

3) I disagree with your analysis of meta data. We do not carry it with
the main data streams precisely because it is unnecessary overhead.
Userspace knows what it setup and what it read. (If your stream is not
controlled from userspace then fair enough, you need meta data).
The meta data is valid whenever the buffer is enabled and hence can be
read once, out of band.

4) The reason for the weird 'fake' floating point (which I agree is
clunky) is the enormous range of real values one sees.  Straight integer
just doesn't give you enough space.  Hence we cheat and use
those two integers with a variable definition of what they mean.
It's all that we have found that works for the devices we have seen.
It's a wierd world but I doubt you'll find a single integer works in
all cases.  Microvolts is incidently not a very fine granularity at all.
Some of the values we have are already in picovolts and there are
nastier devices out there.

5) On the sysfs naming, this is lifted from what hwmon does.  The naming
channel types has worked well for them so there is a lot of support for
it.  The two indexes are for flexibility and come from our decisions on
channel naming.  If we are going to have temp0, temp1 etc and in0 in1
etc then we need one to do the naming index and one to do the location
in the buffer (ordering is always maintained).  Agreed if you argue the
naming is a bad choice, then you could just use one. So this is clearly
tied up with the previous point.

6)  On the precision control bit I'm a little unclear what you mean but
will take a punt...

Devices have radically different precisions, 8 bit to 24 bit so far in
IIO. Without this we have to store 4 times the data (as always align to
save time) for the 8 bit devices. Is this what you mean?  If so you've
just multiplied your data size by 4 in order to avoid a little bit of
trivial handling code.  Again a difference of opinion.  Note we don't
allow these to be changed at run time (more or less, there is one
exception which is when there is a hardware buffer involved).

7) Buffer file operations stuff.  Trivial to add. I certainly intend to
do mmapped (and for that matter splice) as soon as buffers exist that
use it.  Was kind of hoping something nice would come out of the tracing
guys trying to unify their buffers, but not seen anything yet.

8) concurency support if really needed can be done in userspace. I'd
consider it decidely odd if you have a high speed read application where
concurrent reading makes sense.  We talked about this ages ago and
concluded it wasn't worth the hassle.
True concurrent reader buffers are a pain.  See the fun evdev goes
through and they definitely aren't trying to handle much data.

9) I suspect the disagreement about scan's may be down to the types of
hardware involved.  A lot of devices I see are 'only' capable of reading
sets of channels together.  We could then demux them into
multiple buffers (one per channel as you have done), but only by adding
considerable overhead. These share a timestamp, so if nothing else we
only want to save one copy of that.  I'll have to have a close look at
your code to understand what your data flow actually looks like. Perhaps
I am completely missunderstanding it.

10) Buffer type choice at runtime is not there as you say. Note that the
infrastructure is there though after the inkernel push interface patches
merge (they use a demux unit to handle splitting our 'scans' coming from
hardware out to as many buffers as one likes.  However to do this
coherently we would have to have all buffers registered at the start or
disassociate them from the iio device in some way.  Note this may be a
pass through if a given buffer wants all the channels.)  So it can be
done, but we haven't yet had a usecase.  This has been on my todo list,
but not urgent as of yet!

11) I am intrigued to know what could be easier in associating a trigger
to a device than writing the trigger's 'name' value returned from the
oponomous sysfs attribute into 'current_trigger' of the
device you wish to trigger?  This is entirely a userspace operation.
You can set a default if it makes sense (typically data ready signal
of the same device).

12) The stuff about instance management for triggers only applies to
one very special trigger type.  This is the userspace sysfs trigger.
Any trigger associated with hardware is initialized from board files
describing the hardware. We would probably do the same with a high
res timer trigger, but though one has been proposed it isn't ready
to merge as yet.

13) Event's used to configure a trigger value? I'm not sure what you
mean by that. Perhaps it is a disconnnect in what 'events' mean to each
of us?  Anything can be a trigger is someone rights a driver that
exports it as such.

14) There is nothing to stop developers declaring channel specific
attributes. If there is a channel related control that is fairly general
then it should not be separately registered but instead added to the
channel_info mask.  That way it is available for inkernel control from
other drivers.  If it is very much device specific (and very few things
actually are) then there is nothing to stop it being added.

15) The address field being used to give the mask is a spurious point as
the full channel structure is also available so translation to addresses
is trivial if needed.  Note this isn't the case for non channel related
attributes, hence the address is used differently.

16) Concurrent processes can change attributes, but only in non
distructive ways (from stability point of view anyway).  For example,
buffer contents is protected. If a buffer is live then no one can edit
what goes into it.  Hence userspace should setup and initialize the
buffer then check that it is set to what it wants it to be set to before
opening / reading from it.  I am unclear what else you would suggest
protecting?

17) I take your point on the event open/close issues.  Events are one
bit we aren't really happy with!  Devices ought to have opened the file
before turning anything on, so this probably doesn't make any difference
in practice, but as you say it is inconsistent.

18) Can add a warning about registering the buffer before the device I
guess if getting this wrong is common! First report on that one.

Bits and bobs from your table at the end.  Note some of these are
considerations of how we could adapt the code to make it fit your
usecase better.

Buffers only currently work on a sample by sample basis. Technically
there is nothing stopping us from adding a 'push lots' optional
callback.  Getting this to interact well with the demux code needed for
inkernel users would require an optional unroll into individual samples
though.  This doesn't occur in the case where the buffer 'contains
everything' that is captured.  Not too bad, but not pain free.  Kind of
need this anyway to handle chaining a hardware buffer into a software
buffer.

As above, I think the trigger instance confusion is based on reading one
fairly odd trigger type.

Offset gain etc inconsistency of naming bothers me.  These certainly
should be consistent!  There are some drivers in need of cleanup that
may have confused the issue here.  These  are tightly defined by the abi
spec and mostly implemented via the info_mask of the channels.

The number of devices limit arguement is spurious.  If you are using
chrdevs then your number of devices is limited by what it is considered
polite to request.  we set it at 256 as that is considered reasonable.
Could trivially make it a compile time configurable option.  Note we
will only have one iio device per set of triggerable channels (e.g. if
it looks like two separable devices from a data flow point of view, it
will be registered as such.).

Good point on the timestamp limitations. Easy to work around though, but
making the special treatement of timestamps happen only if it is both a
timestamp and not indexed.  Any 'real' channel should be indexed or have
a modifier so this is valid.  Two line patch I think.  Only worth doing
when there is a user though!

Anyhow, I will be interested to have a read of your proposed code.

The big difference I think are that you split data out into independent
buffers, one per channel.  We use the concept of scan's because that is
often how adcs actually work and cuts the overhead to minimum.  Two
options and which is best is probably dictated by the use case.

Other big one is that our output support is currently minimal to say the
least.

Will be interesting to compare.

Jonathan

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Lars-Peter Clausen]

On 11/27/2011 12:05 PM, Jonathan Cameron wrote:
> Hi All,
> 
> I'm posting this reply to linux-iio as it may cut down on the amount of
> repeated discussion and allow us to draw everyone relevant together.
> Please CC anyone relevant (I've just added Greg and Lars-Peter as they
> commented on the ZIO RFC and hence are probably at least vaguely
> interested.)
> 
> Federico asked me to comment on the zio wiki page analysing IIO a week
> or so ago.  I didn't get round to it until yesterday (was prompted to
> take the time to do it by their posting of the patch series).
> 
> Anyhow, my points below are intended more for discussion than anything
> else.  There are clearly things we can learn from each other and I
> suspect at some point the question of whether we can merge (or at least
> share some infrastructure) will come up so it is worth keeping that in
> mind as we go. Targets are different but there will clearly be a blurred
> region between the two!  There are strengths and weaknesses to both
> approaches so lets work out what they are and make sure we agree the facts.
> 
> Jonathan
> 
>> Hello Mr Cameron,
>>
>> I'm working on a new linux framework for data acquisition systems, ZIO.
>> The open hardware repository (http://www.ohwr.org/) hosts the ZIO
>> project at http://www.ohwr.org/projects/zio/.
>>
>> Before starting with this project I analyzed both COMEDI and IIO to
>> undestand if they comply with our requirements, and they don't. I'm glad
>> if you can read my analysis about IIO on the wiki page of the ZIO project,
>> and give me your opinion. There is not much documentation about IIO, so I
>> read the entire code to understand how it works; maybe I misunderstood
>> something and you can correct me where I'm wrong in my analysis.
>> Bear in mind that our main case are boards with mega-samples for second
>> and with a time-stamp precision of sub-nanoseconds. Data output is as
>> important as data input and we don't handle small sets of samples.
>>
>> I think that IIO is a good work (absolutely better the COMEDI) but it
>> doesn't meet with our requirements and is directed toward a different
>> target (small chips). The first time, I analyzed the IIO version within kernel
>> 2.6.38/39 and I really appreciate the improvements done about sysfs
>> centralization and channel organization, but there are some points
>> where I still disagree.
>>
>> The ZIO project is under development at this time, but we think that
>> we'll submit a patch in one or two weeks based on the linux next tree;
>> Greg K.H. suggests us to write also on the IIO mailing list when the ZIO
>> patch is submitted.
>>
>> PS: English is not my native language, so ... I'm sorry.
> Would you mind if I posted this to linux-iio as well?  It might save us
> all some time.  (If you don't mind and want to reply, then just cc the list)
> 
> Sorry I didn't get to this earlier. Things have been a bit manic for the
> last few weeks.
> 
> Anyhow, overview of IIO is mostly fair and accurate. Few minor comments
> though (particularly as you've now posted and received the predictable
> questions!)  Note some of these refer to changes we could make,
> obviously your consideration is based on what is there so they don't
> directly apply to the web page.
> 
> 1) Number of devices is currently limited at 256 entirely because it is
> considered rude to request many more devices than you actually expect to
> see.  Can up this the moment someone actually says they have a reason to
> do so.
> 
> 2) Output signal support is patchy and currently unbuffered, but there
> is some.  Agreed it is rubbish.  Analog Devices were putting some effort
> in on this front, but  I don't know what stage it reached.
> It wasn't of interest to me so wasn't in the early code.

Support for output buffers and trigger output is on my TODO list and will
probably work on it soon.

> 
> 3) I disagree with your analysis of meta data. We do not carry it with
> the main data streams precisely because it is unnecessary overhead.
> Userspace knows what it setup and what it read. (If your stream is not
> controlled from userspace then fair enough, you need meta data).
> The meta data is valid whenever the buffer is enabled and hence can be
> read once, out of band.

I agree, some of the metadata fields look like they should not be in there,
like minor, major, devicename, ....
As Jonathan says all this information is already available to the
application processing the datastream. And the only usecase for having the
metadata interleaved with the real data is that you just want to dump the
stream right onto storage without further processing.

> 
> 4) The reason for the weird 'fake' floating point (which I agree is
> clunky) is the enormous range of real values one sees.  Straight integer
> just doesn't give you enough space.  Hence we cheat and use
> those two integers with a variable definition of what they mean.
> It's all that we have found that works for the devices we have seen.
> It's a wierd world but I doubt you'll find a single integer works in
> all cases.  Microvolts is incidently not a very fine granularity at all.
> Some of the values we have are already in picovolts and there are
> nastier devices out there.
> 

I guess longterm we probably want something else for this anyway, since the
current method is quite limited in resolution which already results in
inaccuracies with the devices we have today.

> [...]
> 
> Bits and bobs from your table at the end.  Note some of these are
> considerations of how we could adapt the code to make it fit your
> usecase better.
> 
> Buffers only currently work on a sample by sample basis. Technically
> there is nothing stopping us from adding a 'push lots' optional
> callback.  Getting this to interact well with the demux code needed for
> inkernel users would require an optional unroll into individual samples
> though.  This doesn't occur in the case where the buffer 'contains
> everything' that is captured.  Not too bad, but not pain free.  Kind of
> need this anyway to handle chaining a hardware buffer into a software
> buffer.
> 

I'm wondering how this bulk mode in ZIO works. Does the hardware simply
generate a bunch of samples after a trigger event, or do you have a buffer
inside the hardware and it periodically takes samples and you flush the
hardware buffer on a trigger event?

> [...]
> 
> Good point on the timestamp limitations. Easy to work around though, but
> making the special treatement of timestamps happen only if it is both a
> timestamp and not indexed.  Any 'real' channel should be indexed or have
> a modifier so this is valid.  Two line patch I think.  Only worth doing
> when there is a user though!

I wonder if it makes sense to add the concept of timestamp source. A
timestamp source would be associated with an trigger and whenever it is
triggered the timestamp would be read and made available for further
processing by the buffer. One timestamp source would be our nanosecond
clock, others could be generated by external hardware.

> 
> Anyhow, I will be interested to have a read of your proposed code.
> 
> The big difference I think are that you split data out into independent
> buffers, one per channel.  We use the concept of scan's because that is
> often how adcs actually work and cuts the overhead to minimum.  Two
> options and which is best is probably dictated by the use case.
> 
> Other big one is that our output support is currently minimal to say the
> least.
> 
> Will be interesting to compare.
> 

I still think that ZIO is just a subset of IIO. We do use IIO for high speed
data conversion.

The evaluation on the ZIO wiki reads a bit as if it is assumed that IIO is
set in stone. Though I think it should be possible to easily adopt it to the
ZIO needs. If we keep two different frameworks there will be a huge overlap
in functionality and also supported devices.

- Lars

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Alessandro Rubini]

Hello Lars-Peter, sorry for the delay.
You raise different points than Jonathan did, I hope I'm not repeating
stuff Federico already said.

>> 2) Output signal support is patchy and currently unbuffered, but there
>> is some.
 
> Support for output buffers and trigger output is on my TODO list and will
> probably work on it soon.

Good. We'll evaluate it, when available. Thanks.  Time for me to subscribe
to the list, I think...

BTW: when I added output support to zio it was a matter of two hours
(it was unexpected, but the design proved solid).

> I agree, some of the metadata fields look like they should not be in there,
> like minor, major, devicename, ....
> As Jonathan says all this information is already available to the
> application processing the datastream. And the only usecase for having the
> metadata interleaved with the real data is that you just want to dump the
> stream right onto storage without further processing.

Exactly. We have thousands of I/O boards, some PC some PowerPC (thus
the endianness information in the control block), and some even may be
remote -- hostless I/O cards using etherbone
(ohwr.org/projects/etherbone-core).

> I'm wondering how this bulk mode in ZIO works. Does the hardware simply
> generate a bunch of samples after a trigger event, or do you have a buffer
> inside the hardware and it periodically takes samples and you flush the
> hardware buffer on a trigger event?

The cards are serious fpga engines. They have 256MB (or more, or less)
internal RAM to store the actual acquisition, which is later pushed to
the host in big blocks.  We also expect to have a scope-like environment,
where the threshold is actually the trigger event, and we have pre-samples
being sent to the PC -- the FPGA will use the RAM circularly, monitoring
data for the trigger event.

> I wonder if it makes sense to add the concept of timestamp source. A
> timestamp source would be associated with an trigger and whenever it is
> triggered the timestamp would be read and made available for further
> processing by the buffer. One timestamp source would be our nanosecond
> clock, others could be generated by external hardware.

I think it makes sense. For us, the stamp comes from hardware because
the device knows the current time at sub-nanosecond precision, moreover,
the trigger happens much earlier than the DMA is performed -- or
much later for output.

> I still think that ZIO is just a subset of IIO.

I don't think it's a subset: it has a different scope. As said, I don't
want to run zio in small systems, where iio fits well.

> We do use IIO for high speed data conversion.

May I know how high?

Sure I want to run my ad7888 with a 10MHz spi and double buffering
(when federico gets to write the iio code), but that's 625kS to be
shared among the channels -- and I've already some concern about
processing them one at a a time.  We have 640 times as many (4 *
100MS); even if it's burst (not continuous). I doubt I can push them to
the buffers sample-by-sample, and in this case the overhead of our
half-a-kB-per-channel meta information is negligible.

> The evaluation on the ZIO wiki reads a bit as if it is assumed that IIO is
> set in stone.

Yes. That's a problem when you must evaluate something. Federico
started with 2.6.39, actually, where sysfs was much more painful,
and we are happy it's getting better and better.

> Though I think it should be possible to easily adopt it to the ZIO
> needs.

Let's see it over time.  Maybe you are right, or maybe not. Some
design choices can't be changed: you need internal consistency in a
subsystem.  Sure push_block would help, but aren't your buffers
sample-oriented anyways? (a genuine question, not rethoric -- I didn't
personally study the internals to fine details, not yet).

> If we keep two different frameworks there will be a huge overlap
> in functionality and also supported devices.

Overlap happens. I don't see it as a problem. You overlap with
linux-sensors already, and everything overlaps with generic char
devices.

As for devices, you are partly right. Sure we are starting with the
same devices that you are using, but the big ones (our target) may be
zio-only. I have no problems in keeping the AD7* zio drivers
off-the-kernel, since that's iio's use case -- actually we only
expect to only have a few of them, mainly as examples.

/alessandro

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Michael Hennerich]

On 11/29/2011 12:00 PM, Alessandro Rubini wrote:
>
> Hello Lars-Peter, sorry for the delay.
>> We do use IIO for high speed data conversion.
> May I know how high?
>

Hi Alessandro,

Right now we use IIO to capture single work loads at 250MSPS.
User space requests - let's say 1M samples, the IIO driver captures and 
returns data to user space.
(sounds a bit similar to your use case)

Hardware is a Virtex6 FPGA, microblaze softcore running Linux and the 
converter is a AD9467
on an FMC-LPC card.

The per-sample buffer implementations in IIO are purely optional!
You can build your own buffer implementation by using the 
INDIO_BUFFER_HARDWARE flag.

For now the full rate capture is only used for hardware validation 
purposes.
Later it is assumed that there will be data decimation inside the FPGA 
fabric,
so that only a few MSPS sustained data is DMAed into the processor core 
system.
Right now it's not decided whether double buffering or a larger chain is 
required in order
to solve the producer-consumer and latency problems.

But I'm pretty optimistic that there is nothing in IIO which prevents me 
from getting the
right solution in place.

Ideally there is only one subsytem, and not one targeting low-speed and 
another for high speed.


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Alessandro Rubini]

Hello.

> Right now we use IIO to capture single work loads at 250MSPS.
> User space requests - let's say 1M samples, the IIO driver captures and 
> returns data to user space.
> (sounds a bit similar to your use case)

Yes, it's similar.

> Hardware is a Virtex6 FPGA, microblaze softcore running Linux and the 
> converter is a AD9467
> on an FMC-LPC card.

That's similar too. Is the code available somewhere?
 
> The per-sample buffer implementations in IIO are purely optional!
> You can build your own buffer implementation by using the 
> INDIO_BUFFER_HARDWARE flag.

We noticed that flag, but the implementation seemed empty. Actually I
now checked and there are two users, so I'll look better how it is.

I still note that our code is way simpler. We don't deny special
buffers, but they are only needed for dma-aware user space (something
that IIO currently isn't offering even for BUFFER_HARDWARE things).

> But I'm pretty optimistic that there is nothing in IIO which
> prevents me from getting the right solution in place.

No, definitely. We'll keep our eyes open on the project, maybe the
final choice will be IIO for our use case, but it's too early to know.
 
> Ideally there is only one subsytem, and not one targeting low-speed
> and another for high speed.

I disagree. If you were right, iio woudn't be in the kernel, as comedi
was already there. (This doesn't mean I am pushing for in-kernel zio
at this point in time).

Thank you for the information
/alessandro

Re: [Device-drivers-devel] ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Getz, Robin]

On 2011-11-29 15:17:32 GMT Alessandro wrote:
>On 2011-11-29 14:31:11 GMT Lars-Peter wrote:
> > I just think it's a waste of resources to develop two frameworks
> > which have more or less the same architecture and serve the same
> > purpose.
>
> As I wrote in another message, I agree but not completely.  Shouldn't
> we try different ideas any now and then? 

trying ideas in-kernel is a great idea.
Changing the userspace ABI isn't.

> Otherwise we would all be 
> using comedi.  We have kde and gnome (I have neither), we have git and
> mercurial, and a zillion other examples.

I think there is a huge difference between different applications in 
userspace, and different kernel interfaces - creating incompatible userspace 
applications.

While it was true that there was some overlap in the early iio in staging with 
other interfaces - I think most of them have been cleaned up, and the 
duplication has mostly disappeared - I think this was a requirement from 
Greg, and other subsystem maintainers.

I have been complaining for awhile about the similarities between comedi and 
iio, and the userspace problem (people wanting to prototype on a desktop with 
a PCIe card with comedi, are going to need to re-write their entire 
application when moving to an embedded target) - but have not had the time to 
contribute anything to solve the problem.

Using the IIO/Comedi overlap as justification to make a third subsystem which 
overlaps both.... I'm not sure I follow the logic.

On 2011-11-29 18:05:53 GMT, Mark Brown pointed out:
>It's also problematic for driver authors if we end up having to work
>with two separate frameworks that fulfil the same function depending on
>which application users end up using.

Which I think sums up my big concern.


> > But I'm pretty optimistic that there is nothing in IIO which
> > prevents me from getting the right solution in place.
>
> No, definitely. We'll keep our eyes open on the project, maybe the
> final choice will be IIO for our use case, but it's too early to know.

No one is saying that the points you make about IIO aren't valid, or that ZIO 
isn't going to work -- what I think everyone is saying - is let's talk about 
things, and determine what the end user needs are, and what the best solution 
is (It's not like in kernel subsystems don't get re-written over time, but 
the kernel/userspace ABI needs to be stable).

I think all anyone is saying is please give us more feedback, and stay 
involved.

> but currently our abstraction is much simpler to use. 

I don't think that IIO is complicated - but it might be. It's easy to say that 
when you are familiar with something. I'm sure that the documentation needs 
more work - if you want to point out the sections that aren't clear - let us 
know.

It also could be that ZIO doesn't handle the end user cases which created the 
need for the "complication" in the API... It's difficult to say without more 
details.

>I think we'll knock for feedback again when we have some drivers 
>and some performance figures, meanwhile we'll continue developing in 
>the zio list, keeping an eye on iio.

I think that's OK - but again - it would be good for everyone here to better 
understand your use cases - so when we are working on our AD9739A 2.4 GSPS 
DAC IIO driver, we can try to make sure that we incorporate what you are 
looking for.

The hardware (PCB) description, and HDL only solution is here:
http://wiki.analog.com/resources/fpga/xilinx/fmc/ad9739a
we are just waiting for production hardware to show up to start on the IIO 
side...

-Robin

RE: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Hennerich, Michael]

Alessandro Rubini wrote on 2011-11-29:
> Hello.
>
>> Right now we use IIO to capture single work loads at 250MSPS. User
>> space requests - let's say 1M samples, the IIO driver captures and
>> returns data to user space. (sounds a bit similar to your use case)
>
> Yes, it's similar.
>
>> Hardware is a Virtex6 FPGA, microblaze softcore running Linux and the
>> converter is a AD9467
>> on an FMC-LPC card.
>
> That's similar too. Is the code available somewhere?

No - it's not yet available. We're currently validating HW, HDL and software.
It will be available in a few days/weeks.

Check out wiki.analog.com

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Lars-Peter Clausen]

On 11/29/2011 12:00 PM, Alessandro Rubini wrote:
> Hello Lars-Peter, sorry for the delay.
> You raise different points than Jonathan did, I hope I'm not repeating
> stuff Federico already said.
> 
>>> 2) Output signal support is patchy and currently unbuffered, but there
>>> is some.
>  
>> Support for output buffers and trigger output is on my TODO list and will
>> probably work on it soon.
> 
> Good. We'll evaluate it, when available. Thanks.  Time for me to subscribe
> to the list, I think...
> 
> BTW: when I added output support to zio it was a matter of two hours
> (it was unexpected, but the design proved solid).
> 
>> I agree, some of the metadata fields look like they should not be in there,
>> like minor, major, devicename, ....
>> As Jonathan says all this information is already available to the
>> application processing the datastream. And the only usecase for having the
>> metadata interleaved with the real data is that you just want to dump the
>> stream right onto storage without further processing.
> 
> Exactly. We have thousands of I/O boards, some PC some PowerPC (thus
> the endianness information in the control block), and some even may be
> remote -- hostless I/O cards using etherbone
> (ohwr.org/projects/etherbone-core).

Yes, but you can inject the meta information in userspace, this does not
have to come from kernel space, or am I missing something.

> 
>> I'm wondering how this bulk mode in ZIO works. Does the hardware simply
>> generate a bunch of samples after a trigger event, or do you have a buffer
>> inside the hardware and it periodically takes samples and you flush the
>> hardware buffer on a trigger event?
> 
> The cards are serious fpga engines. They have 256MB (or more, or less)
> internal RAM to store the actual acquisition, which is later pushed to
> the host in big blocks.  We also expect to have a scope-like environment,
> where the threshold is actually the trigger event, and we have pre-samples
> being sent to the PC -- the FPGA will use the RAM circularly, monitoring
> data for the trigger event.

Hm, so the FPGA will sample the data on a trigger event and put it into the
FPGA memory and the host CPU will periodically move data from this buffer to
storage. Is this understanding correct?
Will the FPGA insert a timestamp per sample or per block moved from the FPGA
to storage?

> 
>> I wonder if it makes sense to add the concept of timestamp source. A
>> timestamp source would be associated with an trigger and whenever it is
>> triggered the timestamp would be read and made available for further
>> processing by the buffer. One timestamp source would be our nanosecond
>> clock, others could be generated by external hardware.
> 
> I think it makes sense. For us, the stamp comes from hardware because
> the device knows the current time at sub-nanosecond precision, moreover,
> the trigger happens much earlier than the DMA is performed -- or
> much later for output.
> 
>> I still think that ZIO is just a subset of IIO.
> 
> I don't think it's a subset: it has a different scope. As said, I don't
> want to run zio in small systems, where iio fits well.
> 
>> We do use IIO for high speed data conversion.
> 
> May I know how high?
> 
> Sure I want to run my ad7888 with a 10MHz spi and double buffering
> (when federico gets to write the iio code), but that's 625kS to be
> shared among the channels -- and I've already some concern about
> processing them one at a a time.  We have 640 times as many (4 *
> 100MS); even if it's burst (not continuous). I doubt I can push them to
> the buffers sample-by-sample, and in this case the overhead of our
> half-a-kB-per-channel meta information is negligible.
> 
>> The evaluation on the ZIO wiki reads a bit as if it is assumed that IIO is
>> set in stone.
> 
> Yes. That's a problem when you must evaluate something. Federico
> started with 2.6.39, actually, where sysfs was much more painful,
> and we are happy it's getting better and better.

What I meant was that you can actively contribute to IIO and implement the
features you need and don't have to wait until they show up in the
framework. E.g. most of the issue mentioned are minor and easy to fix.

> 
>> Though I think it should be possible to easily adopt it to the ZIO
>> needs.
> 
> Let's see it over time.  Maybe you are right, or maybe not. Some
> design choices can't be changed: you need internal consistency in a
> subsystem.  Sure push_block would help, but aren't your buffers
> sample-oriented anyways? (a genuine question, not rethoric -- I didn't
> personally study the internals to fine details, not yet).
> 
>> If we keep two different frameworks there will be a huge overlap
>> in functionality and also supported devices.
> 
> Overlap happens. I don't see it as a problem. You overlap with
> linux-sensors already, and everything overlaps with generic char
> devices.

I just think it's a waste of resources to develop two frameworks which have
more or less the same architecture and serve the same purpose.

> 
> As for devices, you are partly right. Sure we are starting with the
> same devices that you are using, but the big ones (our target) may be
> zio-only. I have no problems in keeping the AD7* zio drivers
> off-the-kernel, since that's iio's use case -- actually we only
> expect to only have a few of them, mainly as examples.
> 
> /alessandro

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Alessandro Rubini]

Hello Lars.

> Yes, but you can inject the meta information in userspace, this does not
> have to come from kernel space, or am I missing something.

It does not _have_, but it is useful to. For example, we can have a
monitoring application that looks at all meta-information flowing
while the real application handles the data.  The monitor didn't
configure the hardware, yet it can read the control files and be
synced with data flow.  (Support for multiple non-conflicting readers
is not implemented yet, but it's in the queue and it's pretty easy to
have).

> Hm, so the FPGA will sample the data on a trigger event and put it into the
> FPGA memory and the host CPU will periodically move data from this buffer to
> storage. Is this understanding correct?

More or less. The card will DMA. With appropriate buffers it will DMA
to user space or to mmapped memory (sure in this case only one reader
can have the data, but still the meta-data is available to many
users).

> Will the FPGA insert a timestamp per sample or per block moved from the FPGA
> to storage?

Per block. If it's a burst, you know the data rate anyways (for us it
is in the meta-data).

> What I meant was that you can actively contribute to IIO and implement the
> features you need and don't have to wait until they show up in the
> framework.

Yes, you are right, I'm aware of it. But you are also aware that it's
not that easily done, when the project has already taken some
directions.  Let me repeat: we'll keep an eye on IIO, even submitting
patches when it makes sense to (and I'm serious about it).

> E.g. most of the issue mentioned are minor and easy to fix.

But write support is not. Nor is DMA to user space or just mmap.

> I just think it's a waste of resources to develop two frameworks
> which have more or less the same architecture and serve the same
> purpose.

As I wrote in another message, I agree but not completely.  Shouldn't
we try different ideas any now and then? Otherwise we would all be
using comedi.  We have kde and gnome (I have neither), we have git and
mercurial, and a zillion other examples.

Maybe at the end we'll go IIO for the accelerators, but currently our
abstraction is much simpler to use.  Sure it lacks users at this
point, but I think it's worth pushing our abstraction further into
real data streams and concurrent users.

I think we'll knock for feedback again when we have some drivers and
some performance figures, meanwhile we'll continue developing in the
zio list, keeping an eye on iio.

thanks again for your feedback
/alessandro

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Mark Brown]

On Tue, Nov 29, 2011 at 03:31:11PM +0100, Lars-Peter Clausen wrote:
> On 11/29/2011 12:00 PM, Alessandro Rubini wrote:

> > Overlap happens. I don't see it as a problem. You overlap with
> > linux-sensors already, and everything overlaps with generic char
> > devices.

> I just think it's a waste of resources to develop two frameworks which have
> more or less the same architecture and serve the same purpose.

It's also problematic for driver authors if we end up having to work
with two separate frameworks that fulfil the same function depending on
which application users end up using.

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Federico Vaga]

Thank you again for your answer.

> 1) Number of devices is currently limited at 256 entirely because it...

I know that in IIO it is just a define to change, but as is, it is
limited to 256. Yes, It sounds like an excuse, my apologies. In our
systems we can have hundreds of board for many kilometers, 256
probably it is not enough. Anyways, there is no overhead in asking for
many minors, IIRC.

> 2) Output signal support is patchy and currently unbuffered, but there ...

We need output to generate waveforms, again with big amounts of data

> 3) I disagree with your analysis of meta data. We do not carry it with...

In our use case the board can be on a machine, but data is analyzed on
an other one.  Again meta-information are fundamental for
post-analysis of thousands on MB of samples; 2 days later we can't
query devices to know which was their configuration. We can also use
meta-information to pre-setup a device output offline, and then
configure it immediately when is required.

> 4) The reason for the weird 'fake' floating point (which I agree is ...

You are right, mircovolt some times are insufficient, but we still
prefer integer because both kernel and device handle integers;
user-space can interpret the value by knowing the device detail. In ZIO
we currently suggest to use microvolts, and we know that we must clarify the
concept, because microvolts are not enough.

> 6) On the precision control bit I'm a little unclear what you mean but ...

Devices can change resolution in order to perform a faster acquisition,
so it can change at run-time. We set the sample size at the maximum needed
by device to make the framework easy. If the board has 16bit
resolution but can work also with 14 or 8 ... then we always use
2bytes for that channel.

> 7) Buffer file operations stuff.  Trivial to add. ...

Ack.

> 8) concurency support if really needed can be done in userspace....

I was meaning spinlock, semaphores and all this stuff. We'd like to
avoid them in the low-level drivers, as the core should take care
of all the complexities (as far as possible, obviously).

> 9) I suspect the disagreement about scan's may be down to the types...

Demux an interleaved scan is a waste of time, you are right. What I
don't understand is why IIO use an index scan? Is it possible to change
it on run time? If it is not, the scan order never change, so why don't
you use a single index for both naming and scan order?

We are studying a solution for interleaved I/O, which is currently
missing from ZIO, so at the moment we can't propose a solution, maybe
in next time.

> 10) Buffer type choice at runtime is not there as you say.

It's not that mandatory, actually. We want to have it for symmetry
and to help us while developing.

> 11) I am intrigued to know what could be easier in associating a trigger ...

What are you referring to? I think is ok assign a trigger by
name. Probably we misunderstood with point 12.

> 12) The stuff about instance management for triggers only applies...

Sure, you are right; but what if you have a generic trigger suitable
for many devices? I think the IIO solution is the same of the sysfs
trigger where user space need to create each instance by hand, and
then assign to a device.  For example, a device family has the same
identical trigger; to avoid code duplication by coping the trigger
code in each device driver, you have to write the trigger code as
independent module. Then you need to assign different instance to
different device driver; I think I need to do something like the sysfs
trigger; otherwise, why is done in that way for the sysfs trigger? Am
I wrong?

> 13) Event's used to configure a trigger value? I'm not sure what you ...

Isn't this what is done in the max1363 driver? When you configure
threshold through sysfs, you write the value on device. Aren't you
configuring a trigger threshold? (I don't know the max1363
specification but from the code I suppose you set a register value for
the threshold event)

> 14) There is nothing to stop developers declaring chan ...
> ....
> If it is very much device specific (and very few things
> actually are) then there is nothing to stop it being added.

We like to centralize all the sysfs stuff, common attributes and
specific ones.  For our drivers we chose not to require low-level
developers to write the full sysfs interface.

> 16) Concurrent processes can change attributes, but only in non ...

Boards have many configuration registers and I want to export them to
the host system through sysfs. To avoid unexpected result I want to
serialize the register access. Thus the request to handle concurrency
issues in the core framework.

> 18) Can add a warning about registering the buffer before the device ...

I waste some hours on this only because I call the functions in a different
order; in my opinion it is better an error which stop device registration.

> Bits and bobs from your table at the end. Note some of these are
> considerations of how we could adapt the code to make it fit your
> usecase better.

Thank you very much. We'll keep an eye on IIO as well, trying to see
if our usecase really needs a new framework or some merge can be devised
over time.

> As above, I think the trigger instance confusion is based on reading one
> fairly odd trigger type.

Yes it is; my answer to point 12 still valid

> Anyhow, I will be interested to have a read of your proposed code.
>
> The big difference I think are that you split data out into independent
> buffers, one per channel. We use the concept of scan's because that is
> often how adcs actually work and cuts the overhead to minimum. Two
> options and which is best is probably dictated by the use case.

We plan to offer a buffer for each channel and one for interleaving.
When the acquisition is interleaved, the channel-set is a single
channel.  User-space knows about this and can demux data if it
wants. (Note, it is not implemented yet. But it is our idea at this point)

> Will be interesting to compare.

Actually our main boards are under development, so we cannot code on
them. But probably we code ZIO drivers for some of the IIO devices,
just to test ZIO and to compare with IIO; bear in mind that these kind
of devices are not our target.

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Jonathan Cameron]

On 11/28/2011 08:14 PM, Federico Vaga wrote:
> Thank you again for your answer.
> 
>> 1) Number of devices is currently limited at 256 entirely because it...
> 
> I know that in IIO it is just a define to change, but as is, it is
> limited to 256. Yes, It sounds like an excuse, my apologies. In our
> systems we can have hundreds of board for many kilometers, 256
> probably it is not enough. Anyways, there is no overhead in asking for
> many minors, IIRC.
Fair enough.
> 
>> 2) Output signal support is patchy and currently unbuffered, but there ...
> 
> We need output to generate waveforms, again with big amounts of data
> 
>> 3) I disagree with your analysis of meta data. We do not carry it with...
> 
> In our use case the board can be on a machine, but data is analyzed on
> an other one.  Again meta-information are fundamental for
> post-analysis of thousands on MB of samples; 2 days later we can't
> query devices to know which was their configuration. We can also use
> meta-information to pre-setup a device output offline, and then
> configure it immediately when is required.
Agreed.  That meta data could mostly be added by the userspace capture
app entirely out of band.  It's there until changed.  It wouldn't be
inconcievable to add the hooks and a buffer variant to do much the same
in iio.
> 
>> 4) The reason for the weird 'fake' floating point (which I agree is ...
> 
> You are right, mircovolt some times are insufficient, but we still
> prefer integer because both kernel and device handle integers;
> user-space can interpret the value by knowing the device detail. In ZIO
> we currently suggest to use microvolts, and we know that we must clarify the
> concept, because microvolts are not enough.
Userspace knowing device detail is typically a bad idea for kernel
drivers. You'll get some pushing back on that front!
> 
>> 6) On the precision control bit I'm a little unclear what you mean but ...
> 
> Devices can change resolution in order to perform a faster acquisition,
> so it can change at run-time. We set the sample size at the maximum needed
> by device to make the framework easy. If the board has 16bit
> resolution but can work also with 14 or 8 ... then we always use
> 2bytes for that channel.
Exactly, thus massively increasing your local storge (doubling it for
starters)? There are devices out there that can change over a much wider
range than that.
> 
>> 7) Buffer file operations stuff.  Trivial to add. ...
> 
> Ack.
> 
>> 8) concurency support if really needed can be done in userspace....
> 
> I was meaning spinlock, semaphores and all this stuff. We'd like to
> avoid them in the low-level drivers, as the core should take care
> of all the complexities (as far as possible, obviously).
The only stuff I think we don't protect in the core that you do is
things like scale factors.  In our case perhaps live changes in these
make sense.  Maybe in yours they are always locked down.  Yes we can't
always know what the current value is, but then some stuff like filter
coefficients isn't an instant change anyway...  I'd say whether these
should be fixed is an application issue.  Sounds like in your
applications it makes sense to make these fixed in kernel.  Basically if
it doesn't make the driver or userspace fall over, we are happy for
things to be changed whilst capture is occuring. You want predictable
consistent data. (fair enough)
> 
>> 9) I suspect the disagreement about scan's may be down to the types...
> 
> Demux an interleaved scan is a waste of time, you are right. What I
> don't understand is why IIO use an index scan? Is it possible to change
> it on run time? If it is not, the scan order never change, so why don't
> you use a single index for both naming and scan order?
channel tells whether we  have voltage channel 1 or voltage channel 2.
Or it tells is if it is temperature 1 or temperature 2.

Scan index tells us where it is in the buffer.  So one counts over all
channels (sometimes with gaps) and the counts over channels of a
particular type.  This is to map devices doing more than one type of
channel to numbering schemes that make sense without reading the datasheet.
> 
> We are studying a solution for interleaved I/O, which is currently
> missing from ZIO, so at the moment we can't propose a solution, maybe
> in next time.
cool. Fiddly with your data rates!
> 
>> 10) Buffer type choice at runtime is not there as you say.
> 
> It's not that mandatory, actually. We want to have it for symmetry
> and to help us while developing.
> 
>> 11) I am intrigued to know what could be easier in associating a trigger ...
> 
> What are you referring to? I think is ok assign a trigger by
> name. Probably we misunderstood with point 12.
> 
>> 12) The stuff about instance management for triggers only applies...
> 
> Sure, you are right; but what if you have a generic trigger suitable
> for many devices?
There are actually very few of them.
> I think the IIO solution is the same of the sysfs
> trigger where user space need to create each instance by hand, and
> then assign to a device.  For example, a device family has the same
> identical trigger; to avoid code duplication by coping the trigger
> code in each device driver, you have to write the trigger code as
> independent module.
You can do that if you like. Nothing to stop you that I can think of.
> Then you need to assign different instance to
> different device driver; 
Not at all. If it has hardware and hence should be described in a board
file or device tree and it will be registered by the hardware driver
(that for the individual device). Whether it is in a separate module
or not is irrelevant to this question.

>I think I need to do something like the sysfs
> trigger; otherwise, why is done in that way for the sysfs trigger? Am
> I wrong?
Take generic trigger types.  If it's a gpio, then it's hardware and uses
the standard irq driver and is registered by board file / device tree.

Software timers are in the same category as userspace driver triggers
and as such should be allocated on demand.  Anything else is a waste of
resources (and got roundly flattened in review).

The reason is there are plenty of setups where you want only one capture
trigger for all your devices.  Why create more than one?
> 
>> 13) Event's used to configure a trigger value? I'm not sure what you ...
> 
> Isn't this what is done in the max1363 driver? When you configure
> threshold through sysfs, you write the value on device. Aren't you
> configuring a trigger threshold? (I don't know the max1363
> specification but from the code I suppose you set a register value for
> the threshold event)
No.  You are configuring an event threshold.  They are not 'normally'
used as triggers because it has never yet made sense to do so.
> 
>> 14) There is nothing to stop developers declaring chan ...
>> ....
>> If it is very much device specific (and very few things
>> actually are) then there is nothing to stop it being added.
> 
> We like to centralize all the sysfs stuff, common attributes and
> specific ones.  For our drivers we chose not to require low-level
> developers to write the full sysfs interface.
Indeed. Nor do we.  Only things you have to write are the odd corners
that aren't currently supported by the core.
> 
>> 16) Concurrent processes can change attributes, but only in non ...
> 
> Boards have many configuration registers and I want to export them to
> the host system through sysfs. To avoid unexpected result I want to
> serialize the register access. Thus the request to handle concurrency
> issues in the core framework.
Agreed, where such issues make sense.  Often they don't so you have just
slowed down the access to the device for now purpose.  That's why we do
it when necessary in the drivers.
> 
>> 18) Can add a warning about registering the buffer before the device ...
> 
> I waste some hours on this only because I call the functions in a different
> order; in my opinion it is better an error which stop device registration.
> 
>> Bits and bobs from your table at the end. Note some of these are
>> considerations of how we could adapt the code to make it fit your
>> usecase better.
> 
> Thank you very much. We'll keep an eye on IIO as well, trying to see
> if our usecase really needs a new framework or some merge can be devised
> over time.
Agreed.

>> As above, I think the trigger instance confusion is based on reading one
>> fairly odd trigger type.
> 
> Yes it is; my answer to point 12 still valid
> 
>> Anyhow, I will be interested to have a read of your proposed code.
>>
>> The big difference I think are that you split data out into independent
>> buffers, one per channel. We use the concept of scan's because that is
>> often how adcs actually work and cuts the overhead to minimum. Two
>> options and which is best is probably dictated by the use case.
> 
> We plan to offer a buffer for each channel and one for interleaving.
> When the acquisition is interleaved, the channel-set is a single
> channel.  User-space knows about this and can demux data if it
> wants. (Note, it is not implemented yet. But it is our idea at this point
)
Is this fully described to userspace?  If not you are going to run into
a lot of review feedback that your framework isn't general.  People
really don't like userspace code having to match against a specific
driver.  A lot of our effort has been around avoiding this requirement.
> 
>> Will be interesting to compare.
> 
> Actually our main boards are under development, so we cannot code on
> them. But probably we code ZIO drivers for some of the IIO devices,
> just to test ZIO and to compare with IIO; bear in mind that these kind
> of devices are not our target.
Indeed. Good luck with your more interesting boards ;)  sounds 'fun'.

Jonathan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Federico Vaga]

> > In our use case the board can be on a machine, but data is analyzed on
> > an other one.  Again meta-information are fundamental for
> > post-analysis of thousands on MB of samples; 2 days later we can't
> > query devices to know which was their configuration. We can also use
> > meta-information to pre-setup a device output offline, and then
> > configure it immediately when is required.
> 
> Agreed.  That meta data could mostly be added by the userspace capture
> app entirely out of band.  It's there until changed.  It wouldn't be
> inconcievable to add the hooks and a buffer variant to do much the same
> in iio.

Yes, configuration data is there until changed but it can change really fast and 
we cannot stop the acquisition to wait user-space data collection.

> >> 4) The reason for the weird 'fake' floating point (which I agree is ...
> > 
> > You are right, mircovolt some times are insufficient, but we still...
> 
> Userspace knowing device detail is typically a bad idea for kernel
> drivers. You'll get some pushing back on that front!

We want the kernel part to remain small and simple. User
space has the name in the meta-data, so it will make sense of its stream. I 
think that drivers should only implement mechanisms to interact with device, 
very few policies. User-space must know what it is doing and which device it is 
controlling; intelligence should be in user-space not in kernel, we provide 
tools, user should know the tool before use it (an hammer can be dangerous if 
used in the wrong way, so you need to know what is an hammer and how use it )


> >> 6) On the precision control bit I'm a little unclear what you mean but
>
> Exactly, thus massively increasing your local storge (doubling it for
> starters)? There are devices out there that can change over a much wider
> range than that.

We trade storage for simplicity. You can change resolution on the fly,
but the stream will reman 2-bytes per sample. Not set in stone, but
it's way simpler for fast development.

> > I was meaning spinlock, semaphores and all this stuff. We'd like to
> > avoid them in the low-level drivers, as the core should take care
> > of all the complexities (as far as possible, obviously).
> 
> The only stuff I think we don't protect in the core that you do is
> things like scale factors.  In our case perhaps live changes in these
> make sense.  Maybe in yours ...

No. It's just serializing access (more on this later).

[about trigger assignment]
> >I think I need to do something like the sysfs
> >
> > trigger; otherwise, why is done in that way for the sysfs trigger? Am
> > I wrong?

>From your answer, I don't understand if in this case I need to do something like 
sysfs trigger in IIO.
 
> The reason is there are plenty of setups where you want only one capture
> trigger for all your devices.  Why create more than one?

A battery of the same boards need a single trigger implementation with different 
instances. With ZIO we allocate both buffer and trigger by instances; when the 
trigger/buffer change, then the old instance is destroyed and a new one is 
created. No waste of resources. 

> >> 13) Event's used to configure a trigger value? I'm not sure what you ...
> > 
> > Isn't this what is done in the max1363 driver? When you configure
> > threshold through sysfs, you write the value on device. Aren't you
> > configuring a trigger threshold? (I don't know the max1363
> > specification but from the code I suppose you set a register value for
> > the threshold event)
> 
> No.  You are configuring an event threshold.  They are not 'normally'
> used as triggers because it has never yet made sense to do so.

It is not clear and I don't know device details, just read the driver. But I 
always abstract a trigger as something that when an event occur, then do 
something; so, why throw an event if you do "nothing" when it occurs?

> >> 14) There is nothing to stop developers declaring chan ...
> >> ....
> >> If it is very much device specific (and very few things
> >> actually are) then there is nothing to stop it being added.
> > 
> > We like to centralize all the sysfs stuff, common attributes and
> > specific ones.  For our drivers we chose not to require low-level
> > developers to write the full sysfs interface.
> 
> Indeed. Nor do we.  Only things you have to write are the odd corners
> that aren't currently supported by the core.

But, as I understand, for the odd corners you need to write the
complete sysfs interface for your specific attributes: show, store, register, 
remove ...

> > Boards have many configuration registers and I want to export them to
> > the host system through sysfs. To avoid unexpected result I want to
> > serialize the register access. Thus the request to handle concurrency
> > issues in the core framework.
> Agreed, where such issues make sense.  Often they don't so you have just
> slowed down the access to the device for now purpose.  That's why we do
> it when necessary in the drivers.

Usually configuring means accessing device registers. And this must be
serialized, that's the most common case.  Sure sometimes our locking
slows down without a need but are you really configuring the same
device at the same time from two different cores and must do it
immediately?

Maybe it's different use cases, again. But after all, tasklets and
works are serialized, and the slowdown isn't a problem.


> > We plan to offer a buffer for each channel and one for interleaving.
> > When the acquisition is interleaved, the channel-set is a single
> > channel.  User-space knows about this and can demux data if it
> > wants. (Note, it is not implemented yet. But it is our idea at this point
> Is this fully described to userspace?  If not you are going to run into
> a lot of review feedback that your framework isn't general.  People
> really don't like userspace code having to match against a specific
> driver.  A lot of our effort has been around avoiding this requirement.

Yes, that's what is being evaluated. With our usual overhead, not good
for your use cases (I wouldn't drive an accelerometer with the zio
overhead, especially on small systems).

Thanks again.

-- 
Federico Vaga

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Jonathan Cameron]

Federico Vaga <federico.vaga@gmail.com> wrote:

>> > In our use case the board can be on a machine, but data is analyzed
>on
>> > an other one.  Again meta-information are fundamental for
>> > post-analysis of thousands on MB of samples; 2 days later we can't
>> > query devices to know which was their configuration. We can also
>use
>> > meta-information to pre-setup a device output offline, and then
>> > configure it immediately when is required.
>>
>> Agreed.  That meta data could mostly be added by the userspace
>capture
>> app entirely out of band.  It's there until changed.  It wouldn't be
>> inconcievable to add the hooks and a buffer variant to do much the
>same
>> in iio.
>
>Yes, configuration data is there until changed but it can change really
>fast and
>we cannot stop the acquisition to wait user-space data collection.
>
>> >> 4) The reason for the weird 'fake' floating point (which I agree
>is ...
>> >
>> > You are right, mircovolt some times are insufficient, but we
>still...
>>
>> Userspace knowing device detail is typically a bad idea for kernel
>> drivers. You'll get some pushing back on that front!
>
>We want the kernel part to remain small and simple. User
>space has the name in the meta-data, so it will make sense of its
>stream. I
>think that drivers should only implement mechanisms to interact with
>device,
>very few policies. User-space must know what it is doing and which
>device it is
>controlling; intelligence should be in user-space not in kernel, we
>provide
>tools, user should know the tool before use it (an hammer can be
>dangerous if
>used in the wrong way, so you need to know what is an hammer and how
>use it )
I will be interested to see how that goes down.
>
>
>> >> 6) On the precision control bit I'm a little unclear what you mean
>but
>>
>> Exactly, thus massively increasing your local storge (doubling it for
>> starters)? There are devices out there that can change over a much
>wider
>> range than that.
>
>We trade storage for simplicity. You can change resolution on the fly,
>but the stream will reman 2-bytes per sample. Not set in stone, but
>it's way simpler for fast development.
Fair enough I guess.
>> > I was meaning spinlock, semaphores and all this stuff. We'd like to
>> > avoid them in the low-level drivers, as the core should take care
>> > of all the complexities (as far as possible, obviously).
>>
>> The only stuff I think we don't protect in the core that you do is
>> things like scale factors.  In our case perhaps live changes in these
>> make sense.  Maybe in yours ...
>
>No. It's just serializing access (more on this later).
>
>[about trigger assignment]
>> >I think I need to do something like the sysfs
>> >
>> > trigger; otherwise, why is done in that way for the sysfs trigger?
>Am
>> > I wrong?
>
>>From your answer, I don't understand if in this case I need to do
>something like
>sysfs trigger in IIO.
We could instantiate sysfs triggers on demand like you do. Would add a special case so I am not that keen to do so unless the alternative of specifically creating them does not work.
>
>> The reason is there are plenty of setups where you want only one
>capture
>> trigger for all your devices.  Why create more than one?
>
>A battery of the same boards need a single trigger implementation with
>different
>instances. With ZIO we allocate both buffer and trigger by instances;
>when the
>trigger/buffer change, then the old instance is destroyed and a new one
>is
>created. No waste of resources.
Fair enough.
>
>> >> 13) Event's used to configure a trigger value? I'm not sure what
>you ...
>> >
>> > Isn't this what is done in the max1363 driver? When you configure
>> > threshold through sysfs, you write the value on device. Aren't you
>> > configuring a trigger threshold? (I don't know the max1363
>> > specification but from the code I suppose you set a register value
>for
>> > the threshold event)
>>
>> No.  You are configuring an event threshold.  They are not 'normally'
>> used as triggers because it has never yet made sense to do so.
>
>It is not clear and I don't know device details, just read the driver.
>But I
>always abstract a trigger as something that when an event occur, then
>do
>something; so, why throw an event if you do "nothing" when it occurs?
Different requirement. Could use the same infrastructure but result would be considerably complex I think.  So could merge the two if the requirement is there.  Right now the use cases are rather different.
>
>> >> 14) There is nothing to stop developers declaring chan ...
>> >> ....
>> >> If it is very much device specific (and very few things
>> >> actually are) then there is nothing to stop it being added.
>> >
>> > We like to centralize all the sysfs stuff, common attributes and
>> > specific ones.  For our drivers we chose not to require low-level
>> > developers to write the full sysfs interface.
>>
>> Indeed. Nor do we.  Only things you have to write are the odd corners
>> that aren't currently supported by the core.
>
>But, as I understand, for the odd corners you need to write the
>complete sysfs interface for your specific attributes: show, store,
>register,
>remove ...
Yes but they are rare so we don't know what they are. Note
 that many could only be mapped to integers using magic numbers and in kernel drivers that is pretty much not allowed.
>
>> > Boards have many configuration registers and I want to export them
>to
>> > the host system through sysfs. To avoid unexpected result I want to
>> > serialize the register access. Thus the request to handle
>concurrency
>> > issues in the core framework.
>> Agreed, where such issues make sense.  Often they don't so you have
>just
>> slowed down the access to the device for now purpose.  That's why we
>do
>> it when necessary in the drivers.
>
>Usually configuring means accessing device registers. And this must be
>serialized, that's the most common case.  Sure sometimes our locking
>slows down without a need but are you really configuring the same
>device at the same time from two different cores and must do it
>immediately?
>
>Maybe it's different use cases, again. But after all, tasklets and
>works are serialized, and the slowdown isn't a problem.
>
>
>> > We plan to offer a buffer for each channel and one for
>interleaving.
>> > When the acquisition is interleaved, the channel-set is a single
>> > channel.  User-space knows about this and can demux data if it
>> > wants. (Note, it is not implemented yet. But it is our idea at this
>point
>> Is this fully described to userspace?  If not you are going to run
>into
>> a lot of review feedback that your framework isn't general.  People
>> really don't like userspace code having to match against a specific
>> driver.  A lot of our effort has been around avoiding this
>requirement.
>
>Yes, that's what is being evaluated. With our usual overhead, not good
>for your use cases (I wouldn't drive an accelerometer with the zio
>overhead, especially on small systems).

>
>Thanks again.
 
You are welcome and some interesting stuff. May be some time before I can take in depth look at code though!
>--
>Federico Vaga
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone 
with K-9 Mail. Please excuse my brevity.

Re: ZIO wiki analysis of IIO and why it doesn't meet there requirements [was Re: Industrial Input Output analysis]

[Federico Vaga]

> You are welcome and some interesting stuff. May be some time before I can take
> in depth look at code though!

Maybe you can wait a while for the next release because we want add some new 
features and unfortunately, we are not full-time on this project.

I still think (as Alessandro) that there isn't a big overlap between IIO and 
ZIO, we have different use cases and requirements.

---
Federico Vaga