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