summaryrefslogtreecommitdiffstats
path: root/Documentation/dma-buf-sharing.txt
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2012-12-20 08:14:23 -0500
committerSumit Semwal <sumit.semwal@linaro.org>2013-02-27 04:43:36 -0500
commitf00b4dad9d9eb001a04cf72e8351a2a1b9e99322 (patch)
treef1d7e737c8fa03488249c77eb0c6e5d5db149fcf /Documentation/dma-buf-sharing.txt
parentd895cb1af15c04c522a25c79cc429076987c089b (diff)
dma-buf: implement vmap refcounting in the interface logic
All drivers which implement this need to have some sort of refcount to allow concurrent vmap usage. Hence implement this in the dma-buf core. To protect against concurrent calls we need a lock, which potentially causes new funny locking inversions. But this shouldn't be a problem for exporters with statically allocated backing storage, and more dynamic drivers have decent issues already anyway. Inspired by some refactoring patches from Aaron Plattner, who implemented the same idea, but only for drm/prime drivers. v2: Check in dma_buf_release that no dangling vmaps are left. Suggested by Aaron Plattner. We might want to do similar checks for attachments, but that's for another patch. Also fix up ERR_PTR return for vmap. v3: Check whether the passed-in vmap address matches with the cached one for vunmap. Eventually we might want to remove that parameter - compared to the kmap functions there's no need for the vaddr for unmapping. Suggested by Chris Wilson. v4: Fix a brown-paper-bag bug spotted by Aaron Plattner. Cc: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Tested-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Diffstat (limited to 'Documentation/dma-buf-sharing.txt')
-rw-r--r--Documentation/dma-buf-sharing.txt6
1 files changed, 5 insertions, 1 deletions
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 0188903bc9e1..4966b1be42ac 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three steps:
302 void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) 302 void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
303 303
304 The vmap call can fail if there is no vmap support in the exporter, or if it 304 The vmap call can fail if there is no vmap support in the exporter, or if it
305 runs out of vmalloc space. Fallback to kmap should be implemented. 305 runs out of vmalloc space. Fallback to kmap should be implemented. Note that
306 the dma-buf layer keeps a reference count for all vmap access and calls down
307 into the exporter's vmap function only when no vmapping exists, and only
308 unmaps it once. Protection against concurrent vmap/vunmap calls is provided
309 by taking the dma_buf->lock mutex.
306 310
3073. Finish access 3113. Finish access
308 312