On Mon, 2020-03-30 at 17:58 +0200, Lars-Peter Clausen wrote: > [External] > > On 3/30/20 4:57 PM, Alexandru Ardelean wrote: > > This is WIP. > > It hasn't been tested yet. Mostly serves as base for some discussion. > > > > There have been some offline discussions about how to go about this. > > Since I wasn't involved in any of those discussions, this kind of tries to > > re-build things from various bits. > > > > 1. First approach is: we keep 1 buffer per device, and we make it either > > in/out, which means that for devices that for devices that have both in/out > > 2 iio_dev instances are required, or an ADC needs to be connected on the in > > path and a DAC on out-path. This is predominantly done in the ADI tree. > > > > 2. One discussion/proposal was to have multiple buffers per-device. But the > > details are vague since they were relayed to me. > > One detail was, to have indexes for devices that have more than 1 > > buffer: > > > > Iio_deviceX: > > buffer > > scan_elements > > > > Iio_deviceX: > > BufferY > > scan_elementsY > > BufferZ > > scan_elementsZ > > > > I am not sure how feasible this is for a single chrdev, as when you look at > > the fileops that get assigned to a chrdev, it looks like it can have at > > most two buffers (one for input, out for output). > > > > Multiplexing input buffers can work (from ADCs), but demultiplexing output > > buffers into a DAC, not so well. Especially on a single chrdev. > > > > Question 1: do we want to support more than 2 buffers per chrdev? > > > > This is what ADI currently has in it's tree (and works). > > > > Example, ADC: > > # ls iio\:device3/buffer/ > > data_available enable length length_align_bytes watermark > > # ls iio\:device3/scan_elements/ > > > > in_voltage0_en in_voltage0_index in_voltage0_type in_voltage1_en in_volt > > age1_index in_voltage1_type > > > > Example, DAC: > > # ls iio\:device4/buffer/ > > data_available enable length length_align_bytes watermark > > # ls iio\:device4/scan_elements/ > > > > out_voltage0_en out_voltage0_type out_voltage1_index out_voltage2_en > > out_voltage2_type out_voltage3_index > > > > out_voltage0_index out_voltage1_en out_voltage1_type out_voltage2_inde > > x out_voltage3_en out_voltage3_type > > > > The direction of each element is encoded into the filename of each channel. > > > > Another question is: > > Does it make sense to have more than 1 'scan_elements' folder? > > That is, for devices that would have both in & out channels. > > > > For 'buffer' folders I was thinking that it may make sense to have, > > 'buffer_in' && 'buffer_out'. > > > > So, one idea is: > > > > Iio_deviceX: > > buffer_in > > buffer_out > > scan_elements > > > > Currently, this patch kind of implements 2 buffers per iio_dev/chrdev. > > But the format is: > > > > Iio_deviceX: > > buffer_in > > buffer_out > > scan_elements_in > > scan_elements_out > > I'd make scan_elements as a sub-folder of the buffer folder. And have > symlink for the legacy case > > > Obviously it shouldn't work as-is [as it wasn't tested], but at least gives > > some glimpse of where this could go. > > I believe the basic idea behind the multiple buffers per device was, > that if we do it, we should do it in a way that you can have an > arbitrary number of buffers. E.g. not just one input and output but also > multiple input buffers. > > > 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. For some reason, the idea of more than 1 chrdev per IIO device escaped me. It makes things easier. I'll take a look. I probably need to think about the naming, or how to identify chrdevs per IIO device. Maybe something like: /dev/iio:device0:0 /dev/iio:device0:1 where the 2nd index is /sys/bus/iio/devices/iio:device0/buffer0 /sys/bus/iio/devices/iio:device0/buffer1 or something like that not sure yet how possible it is yet; need to check >
