On 4/5/20 11:49 AM, Jonathan Cameron wrote:
3. A side question is about the 'iio_buffer -> pollq' field. I was
wondering if it would make sense to move that on to 'iio_dev pollq' if
adding multiple buffers are added per-device. It almost makes sense to
unify the 'pollq' on indio_dev.
But, it looks a bit difficult, and would require some more change [which is
doable] if it makes sense for whatever reason.
The only reason to do it, is because the iio_buffer_fileops has a .poll =
iio_buffer_poll() function attached to it. Adding multiple buffers for an
IIO device may require some consideration on the iio_buffer_poll() function
as well.
I think we need one chardev per buffer. Conceptually that is the right
approach in my option since the two buffers are independent streams. But
also from a practical point of view we want to have the ability to have
the buffers opened by different applications. E.g. iio_readdev on the
input buffer and iio_writedev on the output buffer. And there might be
some other operations that wont multiplex as nicely as read/write. The
high speed interface for example would not work as it is right now.
Yup. Separate chardev is pretty much the only option given the poll infrastructure.
In theory could do the anon file trick again but I'm not sure it's worth it
- the vast majority of drivers are still going to be single buffer (I think!)
The main problem I see with the anon file trick is that we use the open
file also as mutual exclusion so only one application can access a
buffer at a time. This means if one application has the main chardev
open no other application will be able to access the buffers (or events).
