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

[David Lechner <dlechner@baylibre.com>]

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. :-)

> 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>