Re: [PATCH v2 0/3] iio: buffer: Fix DMABUF mapping in some systems

["Nuno Sá" <noname.nuno@gmail.com>]

On Mon, 2025-10-06 at 11:44 -0500, David Lechner wrote:
> On 10/6/25 11:25 AM, Nuno Sá wrote:
> > On Mon, 2025-10-06 at 11:18 -0500, David Lechner wrote:
> > > On 10/6/25 11:06 AM, Nuno Sá via B4 Relay wrote:
> > > > This series fixes an issue with DMABUF support in the IIO subsystem
> > > > where
> > > > the wrong DMA device could be used for buffer mapping operations. This
> > > > becomes critical on systems like Xilinx/AMD ZynqMP Ultrascale where
> > > > memory
> > > > can be mapped above the 32-bit address range.
> > > > 
> > > > Problem:
> > > > --------
> > > > The current IIO DMABUF implementation assumes it can use the parent
> > > > device
> > > > of the IIO device for DMA operations. However, this device may not have
> > > > the appropriate DMA mask configuration for accessing high memory
> > > > addresses.
> > > > On systems where memory is mapped above 32-bits, this leads to the use
> > > > of
> > > > bounce buffers through swiotlb, significantly impacting performance.
> > > > 
> > > > Solution:
> > > > ---------
> > > > This series introduces a new .get_dma_dev() callback in the buffer
> > > > access
> > > > functions that allows buffer implementations to specify the correct DMA
> > > > device that should be used for DMABUF operations. The DMA buffer
> > > > infrastructure implements this callback to return the device that
> > > > actually
> > > > owns the DMA channel, ensuring proper memory mapping without bounce
> > > > buffers.
> > > > 
> > > > Changes:
> > > > --------
> > > > 1. Add .get_dma_dev() callback to iio_buffer_access_funcs and update
> > > > core
> > > >    DMABUF code to use it when available
> > > > 2. Implement the callback in the DMA buffer infrastructure
> > > > 3. Wire up the callback in the dmaengine buffer implementation
> > > > 
> > > > This ensures that DMABUF operations use the device with the correct DMA
> > > > configuration, eliminating unnecessary bounce buffer usage and improving
> > > > performance on high-memory systems.
> > > > 
> > > > (AI generated cover. I would not be this formal but I guess is not
> > > > that bad :))
> > > > 
> > > > ---
> > > > Changes in v2:
> > > > - Dropped Fixes tags on the first two patches and Cc stable them instead
> > > >   (as prerequisites for the third patch). 
> > > > - Link to v1:
> > > > https://lore.kernel.org/r/20251002-fix-iio-dmabuf-get-dma-device-v1-0-c1c9945029d0@analog.com
> > > 
> > > Did you not care for my other suggestions in v1?
> > 
> > Completely missed them, sorry! I kind of stop reading in the stable stuff.
> > I'm
> > ok with the helper function. For the clarification I feel it's redundant.
> > The
> 
> I was thinking extra clarification could be helpful for someone new to the IIO
> subsystem. But it would be quite rare to add a new buffer implementation
> anyway.
> So probably not too many people would actually ever read it. :-)

I mean, it does not harm. If you want to add it, I'll hack it (as I feel it
should be a separate patch also covering the other .ops related to DMA buffers).

> 
> > field is called .get_dma_dev() and the description "called to get the DMA
> > channel associated with this buffer" already implies is for DMA buffer. Same
> > as
> > ops like .enqueue_dmabuf().
> > 
> > - Nuno Sá
> 
> I don't feel too strongly about either change, so either way,
> 
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> 

Thx!

- Nuno Sá