Re: IIO comments

[Arnd Bergmann <arnd@arndb.de>]

On Friday 18 March 2011, Jonathan Cameron wrote:
> On 03/18/11 12:47, Arnd Bergmann wrote:
> > On Thursday 17 March 2011, Jonathan Cameron wrote:
> >> On 03/17/11 17:51, Arnd Bergmann wrote:
> >>> I don't completely understand the notation. Regarding the various
> >>> {in0, in1, in2, ...} inputs, is there a fundamental difference between
> >>> them? In the code example I gave, a driver would simply list
> >>> a set of inputs of the same type (IIO_CHAN_IN) and let the core
> >>> enumerate them. What does "in0-in1" mean?
> >>
> >> in0-in1 is a differential adc channel. Literally outputs value on
> >> physical pin 1 subtracted from physical pin 2.
> > 
> > Ok, I see. So these would be fairly hard to enumerate, right?
> > Would it be possible to have one attribute with named "diff%d"
> > and another attribute associated with it that describes which
> > channels are compared?
>
> Could do, but what would it gain us?  If the information is available
> to the core, then it can use it give us the explicit naming? As shown
> below we have to handle holes in the enumeration anyway so this isn't
> to much of a problem.

Maybe I was seeing problems that don't exist here. Wouldn't
you need to numeric identifiers to describe a differential
channel?

I guess if it's always in${i}-in${i+1}, it's still not too hard.

> >>> Ok. I truely hope that most hardware has something like this, but
> >>> we can probably work around it as explained above if not.
> >>
> >> Yes. Though do beware. spi and i2c buses for some of these things
> >> can be 'very' slow and often congested on the actual boards. Hence
> >> we sometimes spend a lot of effort to avoid transactions.
> > 
> > Do the transactions require spinning on the CPU, or do they
> > always  work in the background when they are slow?
> If you have a proper controller it's often DMA based. So the issue
> is more congestion on the bus limiting possible sampling rates than
> cpu load. To a certain extent we can just ignore this issue as long
> as we are open to changes to a driver to minimise bus usage if someone
> has a use case that actually requires it for a given device.

Ok.

	Arnd