multiple dma engines/ ring buffers

multiple dma engines/ ring buffers

[Henk Medenblik]

Hi,

I am struggling with the concept of using two different DMA engines and 
therefore two ring buffer definitions in a single driver.
My purpose is to have two different data paths which I want to select in 
my iio device driver. One of them has the purpose to stream plain ADC 16 
bit data to my backend while the second selection would be a hardware 
FFT core output (complex 32 bit). So which one I stream to the backend 
should be selectable.

Because both paths originate from different parts in my HW design I 
implemented two different DMA engines and therefore I have two different 
dma names. However, how to deal with that in my single driver? Has 
anyone done that?

Regards

Henk

Re: multiple dma engines/ ring buffers

[Alexandru Ardelean]

On Wed, Mar 16, 2022 at 10:47 PM Henk Medenblik <yoda@deathstar2.nl> wrote:
>
> Hi,
>

Hey

> I am struggling with the concept of using two different DMA engines and
> therefore two ring buffer definitions in a single driver.
> My purpose is to have two different data paths which I want to select in
> my iio device driver. One of them has the purpose to stream plain ADC 16
> bit data to my backend while the second selection would be a hardware
> FFT core output (complex 32 bit). So which one I stream to the backend
> should be selectable.
>
> Because both paths originate from different parts in my HW design I
> implemented two different DMA engines and therefore I have two different
> dma names. However, how to deal with that in my single driver? Has
> anyone done that?

This used to be doable only by registering 2 IIO devices, one for each
data path.
One example is in drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
Around line 2273, you will see:

        for (i = 0; i < ST_LSM6DSX_ID_MAX; i++) {
                if (!hw->iio_devs[i])
                        continue;

                err = devm_iio_device_register(hw->dev, hw->iio_devs[i]);
                if (err)
                        return err;
        }

The idea there, is that the driver seems to be a wrapper for multiple
IIO devices.
I believe this was done because some channels have different sample-rates.
But in userspace, you end up having to manage multiple IIO devices,
which go to the same driver.
This isn't necessarily too bad; it depends on who you ask.
So, the idea there is: 1 IIO device,each with 1 IIO DMA buffer.
ADI has also been using this for RF transceivers (one on TX path and
1-2 on RX paths).

A newer method now (and this isn't used much yet), is to register more
than one IIO buffer per IIO device.
So, taking as an example the drivers/iio/adc/adi-axi-adc.c driver.
If you look at  adi_axi_adc_config_dma_buffer() .

The idea there, would be that if you call
devm_iio_dmaengine_buffer_setup() more than once (with different DMA
names), is that you would end up with more than 1 buffer.
There aren't many examples in userspace on how to access the buffers.
There is one in in the kernel in tools/iio/iio_generic_buffer.c .
Basically, you need to do an "ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &buf_fd);".
If you initialize buf_fd to 0, it will give an FD for the first
buffer, and buf_fd = 1 will give an FD to the second buffer.

After getting an FD to the IIO buffer, working with that FD is
business as usual (read / write).

libiio doesn't yet have support for this multi-buffer mechanism; some
more work is required for that.

In any case, what's not clear to me, is whether you want to expose
both datapaths to userpsace, or somehow mux them in the driver.
Either way, the above details should be some good starting hints
(given that I am not aware of the entire context).

Thanks
Alex

>
> Regards
>
> Henk
>