-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DMABUF API v3 #1035
DMABUF API v3 #1035
Conversation
cdf2b53
to
9a4b87a
Compare
Do we need some CMake and ifdef so that things still build on old kernels (pre 5.19?) I think that is what is causing the centos 7 fails.
|
95260ac
to
fd24382
Compare
fd24382
to
1935bf9
Compare
1935bf9
to
f595502
Compare
f595502
to
7f37cb5
Compare
6e3d99e
to
d472f19
Compare
d472f19
to
72b927c
Compare
Updated the PR; it now uses dma-heaps instead of udmabuf to create the DMABUF object. |
72b927c
to
cc6c16a
Compare
Rebased and added a fix so that the DMABUFs are correctly detached from USB after #1136. |
cc6c16a
to
0b9fb1b
Compare
@mhennerich reminder to merge this :) Note that I cannot update the branch anymore as I'm not in ADI's organization, so I cannot rebase it. |
Hi Paul, @nunojsa is in progress testing it on a backported 6.6 Linux kernel with DMABUF. -Michael |
Nice! @nunojsa don't hesitate to ping me if you have problems or questions. |
0b9fb1b
to
3d7ad71
Compare
I finally got to do some testing with this with an ADI updated kernel. Things look good and working. Just some hick ups on the MMAP interface (I guess you're more focused on testing the new API :)). While I'm eager to remove that code from ADI kernel, we still need to support it for at least one release. Anyways, first patch can be squashed in the fixup (just put it like this so it's easier for you to see the change) and the second I guess it needs to be in it's own patch. |
@nunojsa forgot to answer, sorry. LGTM! |
3d7ad71
to
557ebb4
Compare
This function is meant to be used when the data is never accessed directly, but passed around as DMABUF objects. In that case, keeping the data in DMA space means that it doesn't have to be synchronized with the CPU cache, which improves performance, and saves two ioctl calls. When CPU access is disabled, all API functions to access a block's data should not be used. Signed-off-by: Paul Cercueil <[email protected]>
This API function can be used to retrieve a file descriptor of the underlying DMABUF object. This file descriptor can then be used for instance to attach the block to a different device driver for zero-copy applications. Signed-off-by: Paul Cercueil <[email protected]>
The previous DMABUF-based API was refused upstream as it had several problems and was very complex. A lot of that complexity was lifted by making the IIO core a DMABUF importer instead of an exporter. This means that the IIO core is no more responsible for creating the DMABUF objects, and to map them in the DMA space. This task is now delegated to the "dma-heap" kernel driver, available since kernel 5.6, which allows userspace programs to create DMABUF objects from the system heap. The DMABUF interface of the IIO core then simply consists in three IOCTLs: one to attach a DMABUF to the interface, one to detach it, and one to request a data transfer. Signed-off-by: Paul Cercueil <[email protected]>
Implement the .disable_cpu_access() callback. This will only work when the DMABUF interface is used. Signed-off-by: Paul Cercueil <[email protected]>
Implement the .get_dmabuf_fd() callback. This will only work when the DMABUF interface is used. Signed-off-by: Paul Cercueil <[email protected]>
Add support for passing sample data as DMABUF objects between IIO devices, and the USB stack. This mechanism has the benefit that the CPU will never access the data to copy it from one hardware buffer to another, and therefore results in a much higher throughput at a much lower CPU usage. For this new mechanism to work, the DMABUF-based IIO kernel API must be available and used by the local backend, and the FunctionFS stack must also support importing DMABUFs. If those conditions are not met, the standard way of transferring the data will be used. Signed-off-by: Paul Cercueil <[email protected]>
Add an entry in the CMake options table for the WITH_IIOD_USB_DMABUF toggle. Signed-off-by: Paul Cercueil <[email protected]>
We were setting dmabuf_supported to true before calling IIO_DMABUF_ATTACH_IOCTL that can still fail. Thererefore we would be wrongly using the DMABUF interface for things like enqueue/dequeue blocks. Signed-off-by: Nuno Sa <[email protected]>
did another round of testing on this, everything seems good to go. |
🥳 |
I think we missed adding |
Follow-up of #928
These commits will modify how the local-DMABUF interface works, because the interface itself in the kernel changed (as it is not yet upstream).
The local backend will now make use of the "udmabuf" kernel driver, which was added in 5.19, to create DMABUF objects from memfd buffers. These DMABUFs can then be attached to the IIO device and/or other devices from other subsystems, and memory-mapped to access the data.
IIOD has also been modified to support enqueueing DMABUFs to the USB (functionfs) interface, and will support passing the buffers between IIO and USB in a zero-copy fashion.
From a Libiio API standpoint, some changes were introduced:
iio_block_enqueue
will support partial transfers on RX buffers as well;iio_block_enqueue
will default to transferring the full buffer;iio_block_disable_cpu_access
, to disable CPU synchronization with the buffers when doing zero-copy;iio_block_get_dmabuf_fd
which can be used when doing zero-copy as well.