summaryrefslogtreecommitdiffstats
path: root/Documentation/dma-buf-sharing.txt
diff options
context:
space:
mode:
authorTiago Vignatti <tiago.vignatti@intel.com>2015-12-22 19:36:45 -0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2016-02-09 09:25:22 +0100
commit831e9da7dc5c22fd2a5fb64e999f6e077a4338c3 (patch)
treefd781ca5f233f8559189d35f18842277844e6551 /Documentation/dma-buf-sharing.txt
parentbfe981a0952880df43d08a050bf3ae44aaebd795 (diff)
downloadop-kernel-dev-831e9da7dc5c22fd2a5fb64e999f6e077a4338c3.zip
op-kernel-dev-831e9da7dc5c22fd2a5fb64e999f6e077a4338c3.tar.gz
dma-buf: Remove range-based flush
This patch removes range-based information used for optimizations in begin_cpu_access and end_cpu_access. We don't have any user nor implementation using range-based flush. It seems a consensus that if we ever want something like that again (or even more robust using 2D, 3D sub-range regions) we can use the upcoming dma-buf sync ioctl for such. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1450820214-12509-3-git-send-email-tiago.vignatti@intel.com
Diffstat (limited to 'Documentation/dma-buf-sharing.txt')
-rw-r--r--Documentation/dma-buf-sharing.txt19
1 files changed, 8 insertions, 11 deletions
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 480c8de..4f4a84b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -257,17 +257,15 @@ Access to a dma_buf from the kernel context involves three steps:
Interface:
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
enum dma_data_direction direction)
This allows the exporter to ensure that the memory is actually available for
cpu access - the exporter might need to allocate or swap-in and pin the
backing storage. The exporter also needs to ensure that cpu access is
- coherent for the given range and access direction. The range and access
- direction can be used by the exporter to optimize the cache flushing, i.e.
- access outside of the range or with a different direction (read instead of
- write) might return stale or even bogus data (e.g. when the exporter needs to
- copy the data to temporary storage).
+ coherent for the access direction. The direction can be used by the exporter
+ to optimize the cache flushing, i.e. access with a different direction (read
+ instead of write) might return stale or even bogus data (e.g. when the
+ exporter needs to copy the data to temporary storage).
This step might fail, e.g. in oom conditions.
@@ -322,14 +320,13 @@ Access to a dma_buf from the kernel context involves three steps:
3. Finish access
- When the importer is done accessing the range specified in begin_cpu_access,
- it needs to announce this to the exporter (to facilitate cache flushing and
- unpinning of any pinned resources). The result of any dma_buf kmap calls
- after end_cpu_access is undefined.
+ When the importer is done accessing the CPU, it needs to announce this to
+ the exporter (to facilitate cache flushing and unpinning of any pinned
+ resources). The result of any dma_buf kmap calls after end_cpu_access is
+ undefined.
Interface:
void dma_buf_end_cpu_access(struct dma_buf *dma_buf,
- size_t start, size_t len,
enum dma_data_direction dir);
OpenPOWER on IntegriCloud