Skip to content

Local backends to attach to externally created DMABUF fd - #1614

Draft
rodrigo455 wants to merge 6 commits into
mainfrom
staging/dmabuf-external-fd
Draft

rodrigo455 wants to merge 6 commits into
mainfrom
staging/dmabuf-external-fd

Conversation

@rodrigo455

Copy link
Copy Markdown
Collaborator

PR Description

Today, a DMABUF-backed iio_block always uses memory that libiio allocates
itself from a DMA heap (/dev/dma_heap/*). Consumers might already have a
DMABUF object for the memory they want the samples to land in, for example a
GPU buffer exported as a dma-buf. To use IIO with them, the data currently has
to be copied out of the libiio-allocated block.

The kernel side already supports this: IIO_BUFFER_DMABUF_ATTACH_IOCTL accepts
any dma-buf fd. This PR exposes that in libiio, so the IIO DMA engine can write
samples straight into memory owned by the consumer.

The use case here is that even tough CUDA 13.4 can support the import of DMABUF backed
memory, that is only the case on Tegra platform starting with Thor series.

PR Type

  • Bug fix (a change that fixes an issue)
  • New feature (a change that adds new functionality)
  • Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I have commented new code, particularly complex or unclear areas
  • I have checked that I did not introduce new warnings or errors (CI output)
  • I have checked that components that use libiio did not get broken
  • I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

Move the IIO_DMABUF_ATTACH_IOCTL call, its errno mapping and the buffer
bookkeeping out of local_create_dmabuf() into local_attach_dmabuf(), so
that it can be reused to attach DMABUF objects that libiio did not
allocate itself.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio_block_start() is documented to return a pointer-encoded error when
the block's memory cannot be reached by the CPU, but it returned the
data pointer unconditionally. Return -EACCES from iio_block_start(),
iio_block_first() and iio_block_end(), and from
iio_block_foreach_sample(), when the block has no CPU mapping.

All blocks created today have one, so this only takes effect once
backends can create blocks without a CPU mapping.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Allow a block to be backed by a DMABUF object that was allocated by
another driver, e.g. GPU memory exported as a dma-buf, instead of a
buffer that libiio allocates from a DMA heap. This lets the IIO DMA
engine write samples straight into memory owned by the consumer.

The new function duplicates the caller's fd and attaches the duplicate
to the IIO buffer with IIO_DMABUF_ATTACH_IOCTL. The duplicate is the fd
returned by iio_block_get_dmabuf_fd() and is closed by
iio_block_destroy(). Such blocks have no CPU mapping, so the block
accessors return -EACCES and CPU access cannot be re-enabled.

Backends opt in through a new optional create_block_from_dmabuf op,
appended to iio_backend_ops so existing backends and modules are
unaffected and report -ENOSYS. Only the local backend implements it.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add an optional dmabuf_fd argument to BufferStream.create_block() and
Block(). When it is set, the block is created with
iio_buffer_stream_create_block_from_dmabuf() instead of being allocated
by libiio. Such a block has no CPU mapping, so read() and write() raise
an error.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add a BufferStream::create_block(int dmabuf_fd, size_t size) overload
that wraps iio_buffer_stream_create_block_from_dmabuf().

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add a Block(BufferStream, int dmabuf_fd, uint size) constructor and a
BufferStream.create_block(int dmabuf_fd, uint size) overload that wrap
iio_buffer_stream_create_block_from_dmabuf(). Such a block has no CPU
mapping, so fill() and read() throw an IIOException.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
@rodrigo455
rodrigo455 force-pushed the staging/dmabuf-external-fd branch from 274a884 to 5f712e9 Compare November 2, 2026 13:00

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant