[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240119141402.44262-1-paul@crapouillou.net>
Date: Fri, 19 Jan 2024 15:13:56 +0100
From: Paul Cercueil <paul@...pouillou.net>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonathan Corbet <corbet@....net>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>
Cc: Jonathan Cameron <jic23@...nel.org>,
Nuno Sá <noname.nuno@...il.com>,
Michael Hennerich <Michael.Hennerich@...log.com>,
linux-usb@...r.kernel.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org,
Paul Cercueil <paul@...pouillou.net>
Subject: [PATCH v5 0/6] usb: gadget: functionfs: DMABUF import interface
Hi,
This is the v5 of my patchset that adds a new DMABUF import interface to
FunctionFS.
Daniel / Sima suggested that I should cache the dma_buf_attachment while
the DMABUF is attached to the interface, instead of mapping/unmapping
the DMABUF for every transfer (also because unmapping is not possible in
the dma_fence's critical section). This meant having to add new
dma_buf_begin_access() / dma_buf_end_access() functions that the driver
can call to ensure cache coherency. These two functions are provided by
the new patch [1/6], and an implementation for udmabuf was added in
[2/6] - see the changelog below.
This patchset was successfully tested with CONFIG_LOCKDEP, no errors
were reported in dmesg while using the interface.
This interface is being used at Analog Devices, to transfer data from
high-speed transceivers to USB in a zero-copy fashion, using also the
DMABUF import interface to the IIO subsystem which is being upstreamed
in parallel [1]. The two are used by the Libiio software [2].
On a ZCU102 board with a FMComms3 daughter board, using the combination
of these two new interfaces yields a drastic improvement of the
throughput, from about 127 MiB/s using IIO's buffer read/write interface
+ read/write to the FunctionFS endpoints, to about 274 MiB/s when
passing around DMABUFs, for a lower CPU usage (0.85 load avg. before,
vs. 0.65 after).
Right now, *technically* there are no users of this interface, as
Analog Devices wants to wait until both interfaces are accepted upstream
to merge the DMABUF code in Libiio into the main branch, and Jonathan
wants to wait and see if this patchset is accepted to greenlight the
DMABUF interface in IIO as well. I think this isn't really a problem;
once everybody is happy with its part of the cake, we can merge them all
at once.
This is obviously for 5.9, and based on next-20240119.
Changelog:
- [1/6]: New patch
- [2/6]: New patch
- [5/6]:
- Cache the dma_buf_attachment while the DMABUF is attached.
- Use dma_buf_begin/end_access() to ensure that the DMABUF data will be
coherent to the hardware.
- Remove comment about cache-management and dma_buf_unmap_attachment(),
since we now use dma_buf_begin/end_access().
- Select DMA_SHARED_BUFFER in Kconfig entry
- Add Christian's ACK
Cheers,
-Paul
[1] https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/
[2] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api
Paul Cercueil (6):
dma-buf: Add dma_buf_{begin,end}_access()
dma-buf: udmabuf: Implement .{begin,end}_access
usb: gadget: Support already-mapped DMA SGs
usb: gadget: functionfs: Factorize wait-for-endpoint code
usb: gadget: functionfs: Add DMABUF import interface
Documentation: usb: Document FunctionFS DMABUF API
Documentation/usb/functionfs.rst | 36 ++
drivers/dma-buf/dma-buf.c | 66 ++++
drivers/dma-buf/udmabuf.c | 27 ++
drivers/usb/gadget/Kconfig | 1 +
drivers/usb/gadget/function/f_fs.c | 502 ++++++++++++++++++++++++++--
drivers/usb/gadget/udc/core.c | 7 +-
include/linux/dma-buf.h | 37 ++
include/linux/usb/gadget.h | 2 +
include/uapi/linux/usb/functionfs.h | 41 +++
9 files changed, 698 insertions(+), 21 deletions(-)
--
2.43.0
Powered by blists - more mailing lists