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? > >> It would be interesting to work out what the minumum structure > >> required to generate everything associated with a given channel > >> actually looks like... > >> > >> struct CHAN { > >> enum CHAN_TYPE type; > >> int index; (x = 0, y = 1 etc). > > > > Do you have drivers that have sparse indices? The core could simply > > enumerate them when it encounters channels of the same type for > > one device. > > Sadly yes we do. Some IMUs have 3D accelerometer and 2D gyros. Ok, I see. So you might have {x0,y0} for one sensor but {x1,y1,z1} for the other one, right? > > I don't think you need many function pointers. Having a function > > pointer in struct chan is may be a good idea, but if you have > > ten inputs that are all alike, they can all point to the same > > function, right? > Agreed. I had them in there originally but decided it was getting rather > clunky. In a sense this will look a little like taking the current > huge attribute tables and breaking them up into bits associated with > each channel. We may want a certain amount of 'private_data' space > in the channel array as well to allow for things like addresses. Not > sure on that yet though. Makes sense. So you either need a private-data pointer for each element and point that to another static data structure, or you need two arrays of different structures but using the same indices. I think both ways would work, but it would be nice to come up with a cleaner solution. Maybe it could be an anonymous union of an unsigned long and a pointer, so you can initialize either of the two members, depending on how complex the driver needs it. > > 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? > >> For simplicity of review I'm tempted to go with 1 and make the a > >> requirement of all drivers unless someone comes up with a very > >> good reason why we need this functionality. > > > > I would argue for a combination of 1 & 2. Configuring which of the > > two interrupts you want would be determined by the real-time and/or > > power management requirements, but should not be visible to the > > application reading the data, only when setting up the device. > I'd prefer to allow some direct control. There are use cases where > for filtering purposes you are only interested in a particular > length block of data. Still, that control may be the exception > rather than rule. Lets just turn on the 50% by default then > vast majority of users won't ever touch it! 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