summaryrefslogtreecommitdiff
path: root/drivers/dma-buf/dma-buf.c
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2021-06-21 18:17:58 +0300
committerDaniel Vetter <daniel.vetter@ffwll.ch>2021-06-22 19:11:34 +0300
commit89bcadc8f94bd6e6361b5c803ec6f40132e8bace (patch)
tree49f51703de4ac8ead45e9cd23702200353a17730 /drivers/dma-buf/dma-buf.c
parent8c505bdc9c8b955223b054e34a0be9c3d841cd20 (diff)
downloadlinux-89bcadc8f94bd6e6361b5c803ec6f40132e8bace.tar.xz
dma-buf: Document non-dynamic exporter expectations better
Christian and me realized we have a pretty massive disconnect about different interpretations of what dma_resv is used for by different drivers. The discussion is much, much bigger than this change here, but this is an important one: Non-dynamic exporters must guarantee that the memory they return is ready for use. They cannot expect importers to wait for the exclusive fence. Only dynamic importers are required to obey the dma_resv fences strictly (and more patches are needed to define exactly what this means). Christian has patches to update nouvea, radeon and amdgpu. The only other driver using both ttm and supporting dma-buf export is qxl, which only uses synchronous ttm_bo_move. v2: To hammer this in document that dynamic importers _must_ wait for the exclusive fence after having called dma_buf_map_attachment. Reviewed-by: Christian König <christian.koenig@amd.com> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210621151758.2347474-1-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/dma-buf/dma-buf.c')
-rw-r--r--drivers/dma-buf/dma-buf.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d0121402c58c..510b42771974 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -951,6 +951,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unpin);
* the underlying backing storage is pinned for as long as a mapping exists,
* therefore users/importers should not hold onto a mapping for undue amounts of
* time.
+ *
+ * Important: Dynamic importers must wait for the exclusive fence of the struct
+ * dma_resv attached to the DMA-BUF first.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)