Re: IIO comments

From: Jonathan Cameron
Date: Thu Mar 17 2011 - 12:46:35 EST

On 03/17/11 16:46, Jonathan Cameron wrote:
> On 03/17/11 15:03, Arnd Bergmann wrote:
>> On Thursday 17 March 2011, Jonathan Cameron wrote:
>>> On 03/17/11 13:47, Arnd Bergmann wrote:
>>>> What about hardware devices that have multiple unrelated streams
>>>> of buffered input data?
>>> Certainly plausible, but so far the only ones I've seen that actually
>>> do this are really just two bits of silicon in the same plastic
>>> package. They tend to use different i2c addresses or spi chip
>>> selects anyway so as far as the kernel is concerned are completely
>>> separate. You are correct that any device which truly has different
>>> streams of data would indeed need more than one device.
>> Ok.
>>>>>> * One chardev for each iio device
>>>>> currently 1-3. (event line, buffer access, buffer event)
>>>> It would be really nice to unify this, as I said. What
>>>> are the reasons why you think it cannot or should not be
>>>> done?
>>> Simplicity perhaps, but I'll definitely give your suggestions
>>> a go and see where we end up.
>> Since I haven't fully understood the distinction between the
>> three chardevs, it may of course turn out a bad idea, but I
>> think it would simplify the core code if you could assume
>> that every iio device has exactly one chardev interface,
>> so you could give them the same unique number and manage
>> the life time together.
> It simplifies that corner, but I'm a little worried that it
> will add a lot of interlinks between the currently fairly
> disconnected elements that go through a character device.
> If we can keep those links to a minimum (which I think
> we can, but haven't tried yet!) it will be a sensible move.
>>>>>> * Use epoll to wait for data and/or out-of-band messages
>>>>>> * Use chrdev read to get events from the buffer
>>>>> and data?
>>>> I mean get the data associated with the event. The event
>>>> itself as you said does not have any data, so we would not
>>>> need to read it, just to use poll()/epoll() in order to
>>>> wait for it.
>>> Sure. But devices can do a heck of a lot of different events.
>>> (certainly 10's or maybe more). I'm not immediately clear
>>> on how to handle this via poll etc. This is probably just
>>> because I've never tried though!
>> (e)poll can generally distinguish between very few types of
>> activity: data for reading available, space for writing available,
>> out-of-band events (to be read with e.g. ioctl) and errors.
>> If you want to wait for multiple equal types of events for
>> one hardware device, it would be logical to have multiple
>> character devices for them, so a user could open and wait
>> for some of them independent of the others.
>> Intuitively, I would also expect these to be separate iio
>> devices for the same hardware (each with one chardev), but
>> there may be good reasons why that is not possible.
> For reasons above,

Actually in the other branch of the thread. sorry!
> there can only be one iio device per
> physical hardware. We could define some other intermediate
> representation similar to the bus structure we currently have,
> but then I'm not sure where we gain.
> As we only care about single reader cases here,
> the reader can simply configure which events it is interested
> in to be the only ones produced. A good chunk of the sysfs
> interface is concerned with doing this.
> The ioctl approach you suggest can then be used to query what
> actually occurred.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at