|
@@ -5,228 +5,6 @@
|
|
|
<sumit dot semwal at linaro dot org>
|
|
|
<sumit dot semwal at ti dot com>
|
|
|
|
|
|
-This document serves as a guide to device-driver writers on what is the dma-buf
|
|
|
-buffer sharing API, how to use it for exporting and using shared buffers.
|
|
|
-
|
|
|
-Any device driver which wishes to be a part of DMA buffer sharing, can do so as
|
|
|
-either the 'exporter' of buffers, or the 'user' of buffers.
|
|
|
-
|
|
|
-Say a driver A wants to use buffers created by driver B, then we call B as the
|
|
|
-exporter, and A as buffer-user.
|
|
|
-
|
|
|
-The exporter
|
|
|
-- implements and manages operations[1] for the buffer
|
|
|
-- allows other users to share the buffer by using dma_buf sharing APIs,
|
|
|
-- manages the details of buffer allocation,
|
|
|
-- decides about the actual backing storage where this allocation happens,
|
|
|
-- takes care of any migration of scatterlist - for all (shared) users of this
|
|
|
- buffer,
|
|
|
-
|
|
|
-The buffer-user
|
|
|
-- is one of (many) sharing users of the buffer.
|
|
|
-- doesn't need to worry about how the buffer is allocated, or where.
|
|
|
-- needs a mechanism to get access to the scatterlist that makes up this buffer
|
|
|
- in memory, mapped into its own address space, so it can access the same area
|
|
|
- of memory.
|
|
|
-
|
|
|
-dma-buf operations for device dma only
|
|
|
---------------------------------------
|
|
|
-
|
|
|
-The dma_buf buffer sharing API usage contains the following steps:
|
|
|
-
|
|
|
-1. Exporter announces that it wishes to export a buffer
|
|
|
-2. Userspace gets the file descriptor associated with the exported buffer, and
|
|
|
- passes it around to potential buffer-users based on use case
|
|
|
-3. Each buffer-user 'connects' itself to the buffer
|
|
|
-4. When needed, buffer-user requests access to the buffer from exporter
|
|
|
-5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
|
|
|
-6. when buffer-user is done using this buffer completely, it 'disconnects'
|
|
|
- itself from the buffer.
|
|
|
-
|
|
|
-
|
|
|
-1. Exporter's announcement of buffer export
|
|
|
-
|
|
|
- The buffer exporter announces its wish to export a buffer. In this, it
|
|
|
- connects its own private buffer data, provides implementation for operations
|
|
|
- that can be performed on the exported dma_buf, and flags for the file
|
|
|
- associated with this buffer. All these fields are filled in struct
|
|
|
- dma_buf_export_info, defined via the DEFINE_DMA_BUF_EXPORT_INFO macro.
|
|
|
-
|
|
|
- Interface:
|
|
|
- DEFINE_DMA_BUF_EXPORT_INFO(exp_info)
|
|
|
- struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
|
|
|
-
|
|
|
- If this succeeds, dma_buf_export allocates a dma_buf structure, and
|
|
|
- returns a pointer to the same. It also associates an anonymous file with this
|
|
|
- buffer, so it can be exported. On failure to allocate the dma_buf object,
|
|
|
- it returns NULL.
|
|
|
-
|
|
|
- 'exp_name' in struct dma_buf_export_info is the name of exporter - to
|
|
|
- facilitate information while debugging. It is set to KBUILD_MODNAME by
|
|
|
- default, so exporters don't have to provide a specific name, if they don't
|
|
|
- wish to.
|
|
|
-
|
|
|
- DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct dma_buf_export_info,
|
|
|
- zeroes it out and pre-populates exp_name in it.
|
|
|
-
|
|
|
-
|
|
|
-2. Userspace gets a handle to pass around to potential buffer-users
|
|
|
-
|
|
|
- Userspace entity requests for a file-descriptor (fd) which is a handle to the
|
|
|
- anonymous file associated with the buffer. It can then share the fd with other
|
|
|
- drivers and/or processes.
|
|
|
-
|
|
|
- Interface:
|
|
|
- int dma_buf_fd(struct dma_buf *dmabuf, int flags)
|
|
|
-
|
|
|
- This API installs an fd for the anonymous file associated with this buffer;
|
|
|
- returns either 'fd', or error.
|
|
|
-
|
|
|
-3. Each buffer-user 'connects' itself to the buffer
|
|
|
-
|
|
|
- Each buffer-user now gets a reference to the buffer, using the fd passed to
|
|
|
- it.
|
|
|
-
|
|
|
- Interface:
|
|
|
- struct dma_buf *dma_buf_get(int fd)
|
|
|
-
|
|
|
- This API will return a reference to the dma_buf, and increment refcount for
|
|
|
- it.
|
|
|
-
|
|
|
- After this, the buffer-user needs to attach its device with the buffer, which
|
|
|
- helps the exporter to know of device buffer constraints.
|
|
|
-
|
|
|
- Interface:
|
|
|
- struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
|
|
|
- struct device *dev)
|
|
|
-
|
|
|
- This API returns reference to an attachment structure, which is then used
|
|
|
- for scatterlist operations. It will optionally call the 'attach' dma_buf
|
|
|
- operation, if provided by the exporter.
|
|
|
-
|
|
|
- The dma-buf sharing framework does the bookkeeping bits related to managing
|
|
|
- the list of all attachments to a buffer.
|
|
|
-
|
|
|
-Until this stage, the buffer-exporter has the option to choose not to actually
|
|
|
-allocate the backing storage for this buffer, but wait for the first buffer-user
|
|
|
-to request use of buffer for allocation.
|
|
|
-
|
|
|
-
|
|
|
-4. When needed, buffer-user requests access to the buffer
|
|
|
-
|
|
|
- Whenever a buffer-user wants to use the buffer for any DMA, it asks for
|
|
|
- access to the buffer using dma_buf_map_attachment API. At least one attach to
|
|
|
- the buffer must have happened before map_dma_buf can be called.
|
|
|
-
|
|
|
- Interface:
|
|
|
- struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *,
|
|
|
- enum dma_data_direction);
|
|
|
-
|
|
|
- This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the
|
|
|
- "dma_buf->ops->" indirection from the users of this interface.
|
|
|
-
|
|
|
- In struct dma_buf_ops, map_dma_buf is defined as
|
|
|
- struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *,
|
|
|
- enum dma_data_direction);
|
|
|
-
|
|
|
- It is one of the buffer operations that must be implemented by the exporter.
|
|
|
- It should return the sg_table containing scatterlist for this buffer, mapped
|
|
|
- into caller's address space.
|
|
|
-
|
|
|
- If this is being called for the first time, the exporter can now choose to
|
|
|
- scan through the list of attachments for this buffer, collate the requirements
|
|
|
- of the attached devices, and choose an appropriate backing storage for the
|
|
|
- buffer.
|
|
|
-
|
|
|
- Based on enum dma_data_direction, it might be possible to have multiple users
|
|
|
- accessing at the same time (for reading, maybe), or any other kind of sharing
|
|
|
- that the exporter might wish to make available to buffer-users.
|
|
|
-
|
|
|
- map_dma_buf() operation can return -EINTR if it is interrupted by a signal.
|
|
|
-
|
|
|
-
|
|
|
-5. When finished, the buffer-user notifies end-of-DMA to exporter
|
|
|
-
|
|
|
- Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to
|
|
|
- the exporter using the dma_buf_unmap_attachment API.
|
|
|
-
|
|
|
- Interface:
|
|
|
- void dma_buf_unmap_attachment(struct dma_buf_attachment *,
|
|
|
- struct sg_table *);
|
|
|
-
|
|
|
- This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the
|
|
|
- "dma_buf->ops->" indirection from the users of this interface.
|
|
|
-
|
|
|
- In struct dma_buf_ops, unmap_dma_buf is defined as
|
|
|
- void (*unmap_dma_buf)(struct dma_buf_attachment *,
|
|
|
- struct sg_table *,
|
|
|
- enum dma_data_direction);
|
|
|
-
|
|
|
- unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
|
|
|
- map_dma_buf, this API also must be implemented by the exporter.
|
|
|
-
|
|
|
-
|
|
|
-6. when buffer-user is done using this buffer, it 'disconnects' itself from the
|
|
|
- buffer.
|
|
|
-
|
|
|
- After the buffer-user has no more interest in using this buffer, it should
|
|
|
- disconnect itself from the buffer:
|
|
|
-
|
|
|
- - it first detaches itself from the buffer.
|
|
|
-
|
|
|
- Interface:
|
|
|
- void dma_buf_detach(struct dma_buf *dmabuf,
|
|
|
- struct dma_buf_attachment *dmabuf_attach);
|
|
|
-
|
|
|
- This API removes the attachment from the list in dmabuf, and optionally calls
|
|
|
- dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits.
|
|
|
-
|
|
|
- - Then, the buffer-user returns the buffer reference to exporter.
|
|
|
-
|
|
|
- Interface:
|
|
|
- void dma_buf_put(struct dma_buf *dmabuf);
|
|
|
-
|
|
|
- This API then reduces the refcount for this buffer.
|
|
|
-
|
|
|
- If, as a result of this call, the refcount becomes 0, the 'release' file
|
|
|
- operation related to this fd is called. It calls the dmabuf->ops->release()
|
|
|
- operation in turn, and frees the memory allocated for dmabuf when exported.
|
|
|
-
|
|
|
-NOTES:
|
|
|
-- Importance of attach-detach and {map,unmap}_dma_buf operation pairs
|
|
|
- The attach-detach calls allow the exporter to figure out backing-storage
|
|
|
- constraints for the currently-interested devices. This allows preferential
|
|
|
- allocation, and/or migration of pages across different types of storage
|
|
|
- available, if possible.
|
|
|
-
|
|
|
- Bracketing of DMA access with {map,unmap}_dma_buf operations is essential
|
|
|
- to allow just-in-time backing of storage, and migration mid-way through a
|
|
|
- use-case.
|
|
|
-
|
|
|
-- Migration of backing storage if needed
|
|
|
- If after
|
|
|
- - at least one map_dma_buf has happened,
|
|
|
- - and the backing storage has been allocated for this buffer,
|
|
|
- another new buffer-user intends to attach itself to this buffer, it might
|
|
|
- be allowed, if possible for the exporter.
|
|
|
-
|
|
|
- In case it is allowed by the exporter:
|
|
|
- if the new buffer-user has stricter 'backing-storage constraints', and the
|
|
|
- exporter can handle these constraints, the exporter can just stall on the
|
|
|
- map_dma_buf until all outstanding access is completed (as signalled by
|
|
|
- unmap_dma_buf).
|
|
|
- Once all users have finished accessing and have unmapped this buffer, the
|
|
|
- exporter could potentially move the buffer to the stricter backing-storage,
|
|
|
- and then allow further {map,unmap}_dma_buf operations from any buffer-user
|
|
|
- from the migrated backing-storage.
|
|
|
-
|
|
|
- If the exporter cannot fulfill the backing-storage constraints of the new
|
|
|
- buffer-user device as requested, dma_buf_attach() would return an error to
|
|
|
- denote non-compatibility of the new buffer-sharing request with the current
|
|
|
- buffer.
|
|
|
-
|
|
|
- If the exporter chooses not to allow an attach() operation once a
|
|
|
- map_dma_buf() API has been called, it simply returns an error.
|
|
|
|
|
|
Kernel cpu access to a dma-buf buffer object
|
|
|
--------------------------------------------
|