From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Tom Cooksey <tom.cooksey@arm.com>
Cc: 'Rob Clark' <rob.clark@linaro.org>,
linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, rschultz@google.com,
Rob Clark <rob@ti.com>,
sumit.semwal@linaro.org, patches@linaro.org
Subject: Re: [PATCH] RFC: dma-buf: userspace mmap support
Date: Sat, 17 Mar 2012 20:17:19 +0000 [thread overview]
Message-ID: <20120317201719.121f4104@pyx> (raw)
In-Reply-To: <000001cd0399$9e57db90$db0792b0$@cooksey@arm.com>
> > dma-buf file descriptor. Userspace access to the buffer should be
> > bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
> > give the exporting driver a chance to deal with cache synchronization
> > and such for cached userspace mappings without resorting to page
There should be flags indicating if this is necessary. We don't want extra
syscalls on hardware that doesn't need it. The other question is what
info is needed as you may only want to poke a few pages out of cache and
the prepare/finish on its own gives no info.
> E.g. If another device was writing to the buffer, the prepare ioctl
> could block until that device had finished accessing that buffer.
How do you avoid deadlocks on this ? We need very clear ways to ensure
things always complete in some form given multiple buffer
owner/requestors and the fact this API has no "prepare-multiple-buffers"
support.
Alan
WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Tom Cooksey" <tom.cooksey@arm.com>
Cc: "'Rob Clark'" <rob.clark@linaro.org>,
<linaro-mm-sig@lists.linaro.org>,
<dri-devel@lists.freedesktop.org>, <linux-media@vger.kernel.org>,
rschultz@google.com, Rob Clark <rob@ti.com>,
sumit.semwal@linaro.org, patches@linaro.org
Subject: Re: [PATCH] RFC: dma-buf: userspace mmap support
Date: Sat, 17 Mar 2012 20:17:19 +0000 [thread overview]
Message-ID: <20120317201719.121f4104@pyx> (raw)
In-Reply-To: <000001cd0399$9e57db90$db0792b0$@cooksey@arm.com>
> > dma-buf file descriptor. Userspace access to the buffer should be
> > bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
> > give the exporting driver a chance to deal with cache synchronization
> > and such for cached userspace mappings without resorting to page
There should be flags indicating if this is necessary. We don't want extra
syscalls on hardware that doesn't need it. The other question is what
info is needed as you may only want to poke a few pages out of cache and
the prepare/finish on its own gives no info.
> E.g. If another device was writing to the buffer, the prepare ioctl
> could block until that device had finished accessing that buffer.
How do you avoid deadlocks on this ? We need very clear ways to ensure
things always complete in some form given multiple buffer
owner/requestors and the fact this API has no "prepare-multiple-buffers"
support.
Alan
next prev parent reply other threads:[~2012-03-17 20:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-15 1:32 [PATCH] RFC: dma-buf: userspace mmap support Rob Clark
2012-03-15 7:16 ` [Linaro-mm-sig] " Abhinav Kochhar
2012-03-15 12:27 ` Rob Clark
2012-03-15 20:30 ` Rebecca Schultz Zavin
2012-03-15 20:49 ` Rebecca Schultz Zavin
2012-03-16 10:50 ` Marcus Lorentzon
2012-03-16 14:19 ` Rob Clark
2012-03-16 14:19 ` Rob Clark
2012-03-16 17:24 ` Tom Cooksey
[not found] ` <4f637907.8511440a.7941.ffff9067SMTPIN_ADDED@mx.google.com>
2012-03-16 18:55 ` Rob Clark
[not found] ` <000001cd0399$9e57db90$db0792b0$@cooksey@arm.com>
2012-03-17 20:17 ` Alan Cox [this message]
2012-03-17 20:17 ` Alan Cox
2012-03-17 22:12 ` Rob Clark
2012-03-19 16:42 ` Tom Cooksey
[not found] ` <000101cd05ef$3eab78c0$bc026a40$@cooksey@arm.com>
2012-03-19 16:56 ` Alan Cox
2012-03-19 16:56 ` Alan Cox
2012-03-19 17:10 ` [Linaro-mm-sig] " Marcus Lorentzon
2012-03-19 18:44 ` Tom Cooksey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120317201719.121f4104@pyx \
--to=alan@lxorguk.ukuu.org.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=patches@linaro.org \
--cc=rob.clark@linaro.org \
--cc=rob@ti.com \
--cc=rschultz@google.com \
--cc=sumit.semwal@linaro.org \
--cc=tom.cooksey@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.