On Thu, 26 May 2022 at 18:30, Simon Ser contact@emersion.fr wrote:
Document how to obtain the size of a DMA-BUF. This is what Wayland compositors are doing.
Mention the kernel version numbers from which DMA-BUF features are available.
Signed-off-by: Simon Ser contact@emersion.fr Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: Jason Ekstrand jason@jlekstrand.net
include/uapi/linux/dma-buf.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index 8e4a2ca0bcbf..c95f6d3457d2 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -47,9 +47,13 @@
- If the driver or API with which the client is interacting uses implicit
- synchronization, waiting for prior work to complete can be done via
- poll() on the DMA buffer file descriptor. If the driver or API requires
- explicit synchronization, the client may have to wait on a sync_file or
- other synchronization primitive outside the scope of the DMA buffer API.
- poll() on the DMA buffer file descriptor from kernel version 3.17. If the
- driver or API requires explicit synchronization, the client may have to wait
- on a sync_file or other synchronization primitive outside the scope of the
- DMA buffer API.
This looks good, but you missed the DOC: implicit fence polling in dma-buf.c. Probably good to update that too.
- From kernel version 3.12, user-space can use llseek(2) with the ``SEEK_END``
- whence to obtain the size of a DMA-BUF.
This feels misplaced, especially since this ends up under the "DMA Buffer ioctls" heading.
Maybe simplest to just put a "DMA Buffer misc uAPI" section directly into dma-buf.rst and put that section there? Also probably good to add that the size is invariant.
Or if you don't want a new heading, put it somewhere sensible in the mmap section? Also just noticed that the DOC: cpu access section could perhaps link to the relevant ioctl docs here to connect things better. -Daniel
*/ struct dma_buf_sync { /** -- 2.36.1