Message-ID: <60e2d844-418a-4bde-b6ef-76d10448d5ec@bootlin.com>
Date: Fri, 11 Apr 2025 10:14:17 +0200
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Christian König <christian.koenig@....com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

Hi Christian,

On 4/11/25 9:30 AM, Christian König wrote:
> Hi Thomas,
> 
> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
>> Hello Christian,
>>
>> Thanks for your feedback!
>>
>> On Thu, 10 Apr 2025 18:29:12 +0200
>> Christian König<christian.koenig@....com> wrote:
>>
>>>> Many UIO users performing DMA from their UIO device need to access the
>>>> DMA addresses of the allocated buffers. There are out-of-tree drivers
>>>> that allow to do it but nothing in the mainline.
>>> Well that basically disqualifies this patch set in the first paragraph.
>>>
>>> To justify some kernel change we always need an in kernel user of the
>>> interface, since this is purely for out-of-tree drivers this is a
>>> no-go to begin with.
>> I'm not sure to understand your comment here. This patch series is
>> about extending the UIO interface... which is a user-space interface.
>> So obviously it has no "in-kernel user" because it's meant to be used
>> from user-space. Could you clarify what you meant here?
> 
> Bastien wrote about "out-of-tree drivers" which is something the 
> upstream kernel explicitly does not support.
> 

Sorry maybe it wasn't clear, but what I meant is that the goal of this 
series is to replace 'out-of-tree drivers' with something upstream.

> When you make that UIO API and have an open source userspace driver then 
> that is probably a good justification to do this.
> 
> What the kernel community tries to prevent here is that people start 
> using the UAPI to write closed source drivers in userspace.
> 

>>> What you could potentially do is to create an UIO driver which
>>> imports DMA-bufs, pins them and then provide the DMA addresses to
>>> userspace.
>>>
>>> But please be aware that DMA-fences are fundamentally incompatible
>>> with UIO. So you won't be able to do any form of synchronization
>>> which probably makes the implementation pretty limited.
>> Could you clarify why DMA-fences would be needed here, and for what
>> synchronization?
> 
> In general DMA-buf is an interface which enables you do share device 
> specific buffers between different drivers as well as between userspace 
> processes.
> 
> For this to work with for example cameras, GPUs or RDMA NICs you need to 
> some kind of synchronization primitive, e.g. device A can only starts 
> it's DMA transaction when device B has completed his.
> 
> The problem is that this synchronization approach is fundamentally 
> incompatible with UIO. See here for more details: https:// 
> www.kernel.org/doc/html/latest/driver-api/dma-buf.html#indefinite-dma-fences
>
>> The DMA buffers allocated here are DMA coherent buffers. So the
>> user-space application that uses UIO will allocate such buffers once at
>> application start, retrieve their DMA address, and then program DMA
>> transfers as it sees fit using the memory-mapped registers accessible
>> through UIO. I'm not sure which synchronization you are referring to.
>> We are not "chaining" DMA transfers, with for example a camera
>> interface feeding its DMA buffers to an ISP or something like that. The
>> typical use case here is some IP block in an FPGA that does DMA
>> transfers to transfer data to/from some sort of specialized I/O
>> interface. We get an interrupt when the transfer is done, and we can
>> re-use the buffer for the next transfer.
> 
> Well why do you then want to use DMA-buf in the first place? As far as I 
> know what you describe can perfectly be done with the normal UIO memory 
> management interfaces.
> 
> DMA-buf is only interesting when you actually want to share something in 
> between devices or between applications.
>

I wanted to use DMA-buf because it allows to dynamically 
allocate/release coherent buffers from userspace. UIO doesn't provide 
such interface.
I'm aware that exposing DMA addresses to userspace isn't a good 
practice. That's why this series create a new heap specific to UIO that 
will be the only one implementing the new ioctl.


Best regards,
Bastien

Powered by blists - more mailing lists