<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Hi Thomas, Am 10.04.25 um 21:43 schrieb Thomas Petazzoni: <blockquote type="cite" cite="mid:20250410214307.361e373f@windsurf"> <pre class="moz-quote-pre" wrap="">Hello Christian, Thanks for your feedback! On Thu, 10 Apr 2025 18:29:12 +0200 Christian König <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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?</pre> </blockquote> Bastien wrote about "out-of-tree drivers" which is something the upstream kernel explicitly does not support. 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. <blockquote type="cite" cite="mid:20250410214307.361e373f@windsurf"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Could you clarify why DMA-fences would be needed here, and for what synchronization?</pre> </blockquote> 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: <a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#indefinite-dma-fences">https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#indefinite-dma-fences</a> <blockquote type="cite" cite="mid:20250410214307.361e373f@windsurf"> <pre class="moz-quote-pre" wrap="">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.</pre> </blockquote> 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. Regards, Christian. <blockquote type="cite" cite="mid:20250410214307.361e373f@windsurf"> <pre class="moz-quote-pre" wrap="">If you could clarify here as well, it would definitely help in understanding the shortcomings/limitations. Thanks a lot! Thomas Petazzoni </pre> </blockquote> </body> </html>