From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Verkuil Subject: Re: [PATCH] dma-buf: Update docs for SYNC ioctl Date: Mon, 21 Mar 2016 08:40:33 +0100 Message-ID: <56EFA571.1010104@xs4all.nl> References: <1458545443-3302-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1458545443-3302-1-git-send-email-daniel.vetter@ffwll.ch> Sender: linux-media-owner@vger.kernel.org To: Daniel Vetter , DRI Development Cc: Chris Wilson , Tiago Vignatti , =?UTF-8?Q?St=c3=a9phane_Marchesin?= , David Herrmann , Sumit Semwal , Daniel Vetter , linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, intel-gfx@lists.freedesktop.org, devel@driverdev.osuosl.org List-Id: dri-devel@lists.freedesktop.org Hi Daniel, Two small comments: On 03/21/2016 08:30 AM, Daniel Vetter wrote: > Just a bit of wording polish plus mentioning that it can fail and mus= t > be restarted. >=20 > Requested by Sumit. >=20 > Cc: Chris Wilson > Cc: Tiago Vignatti > Cc: St=C3=A9phane Marchesin > Cc: David Herrmann > Cc: Sumit Semwal > Cc: Daniel Vetter > CC: linux-media@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linaro-mm-sig@lists.linaro.org > Cc: intel-gfx@lists.freedesktop.org > Cc: devel@driverdev.osuosl.org > Signed-off-by: Daniel Vetter > --- > Documentation/dma-buf-sharing.txt | 11 ++++++----- > drivers/dma-buf/dma-buf.c | 2 +- > 2 files changed, 7 insertions(+), 6 deletions(-) >=20 > diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-bu= f-sharing.txt > index 32ac32e773e1..5c4e3e586ec8 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 objec= t has 2 main use-cases: > =20 > 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 fa= il with > + -EGAIN or -EINTR, in which case it must be restarted. EGAIN -> EAGAIN > =20 > Some systems might need some sort of cache coherency management e= =2Eg. when > CPU and GPU domains are being accessed through dma-buf at the sam= e time. To > @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer obj= ect has 2 main use-cases: > want (with the new data being consumed by the GPU or say scan= out device) > - munmap once you don't need the buffer any more > =20 > - 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 t= o use > + SYNC_START and SYNC_END before and after, respectively, when acc= essing the > + mapped address. Userspace cannot on coherent access, even when t= here are "Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, = the meaning isn't clear to me. Regards, Hans > + systems where it just works without calling these ioctls. > =20 > 2. Supporting existing mmap interfaces in importers > =20 > 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) >=20