On Tue, 22 May 2012 13:34:38 +0100, Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
Inline comment for one sentence that made no sense.
Signed-off-by: Dave Airlie airlied@redhat.com
Documentation/dma-buf-sharing.txt | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 3bbd5c5..98e9fa0 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves three steps: Note that these calls need to always succeed. The exporter needs to complete any preparations that might fail in begin_cpu_access.
- For some circumstances the overhead of kmap can be too high, a vmap interface
- is introduced. This interface shouldn't be used very carefully, as vmalloc
This interface should be used carefully.
Sparingly would also be appropriate, though in less regular usage than carefully.
- space is a limited resources on many architectures.
- Interfaces:
void *dma_buf_vmap(struct dma_buf *dmabuf)void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)- This call can fail if there is no vmap support in the exporter, or if it
- runs out of vmalloc space. Fallback to kmap should be implemented.
- Finish access