[Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl
dh.herrmann at gmail.com
Mon Mar 21 12:26:58 UTC 2016
On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
> Requested by Sumit.
> v2: Fix them typos (Hans).
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Tiago Vignatti <tiago.vignatti at intel.com>
> Cc: Stéphane Marchesin <marcheu at chromium.org>
> Cc: David Herrmann <dh.herrmann at gmail.com>
> Cc: Sumit Semwal <sumit.semwal at linaro.org>
> Cc: Daniel Vetter <daniel.vetter at intel.com>
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Cc: Hans Verkuil <hverkuil at xs4all.nl>
> Acked-by: Sumit Semwal <sumit.semwal at linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> Documentation/dma-buf-sharing.txt | 11 ++++++-----
> drivers/dma-buf/dma-buf.c | 2 +-
> 2 files changed, 7 insertions(+), 6 deletions(-)
> diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
> No special interfaces, userspace simply calls mmap on the dma-buf fd, making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> - used when the access happens. This is discussed next paragraphs.
> + used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> + -EAGAIN or -EINTR, in which case it must be restarted.
What is "restart on EAGAIN" supposed to mean? Or more generally, what
does EAGAIN tell the caller?
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout device)
> - munmap once you don't need the buffer any more
> - Therefore, for correctness and optimal performance, systems with the memory
> - cache shared by the GPU and CPU i.e. the "coherent" and also the
> - "incoherent" are always required to use SYNC_START and SYNC_END before and
> - after, respectively, when accessing the mapped address.
> + For correctness and optimal performance, it is always required to use
> + SYNC_START and SYNC_END before and after, respectively, when accessing the
> + mapped address. Userspace cannot rely on coherent access, even when there
> + are systems where it just works without calling these ioctls.
> 2. Supporting existing mmap interfaces in importers
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> * @dmabuf: [in] buffer to complete cpu access for.
> * @direction: [in] length of range for cpu access.
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
> int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> enum dma_data_direction direction)
More information about the Intel-gfx