linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Rob Clark <robdclark@gmail.com>
Cc: Sumit Semwal <sumit.semwal@ti.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
	linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, linux@arm.linux.org.uk,
	arnd@arndb.de, jesse.barker@linaro.org, daniel@ffwll.ch
Subject: Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Date: Wed, 12 Oct 2011 15:34:54 +0100	[thread overview]
Message-ID: <CAPM=9tyAiUZ9tNaer=_52WmiLKpJKG+3EXvZzotwGwvqkJFmOQ@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGsK25wk28YmiwsZTenecKqCt6irx66nR-8nOFMo6Z=Dkw@mail.gmail.com>

On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie <airlied@gmail.com> wrote:
>>> But then we'd need a different set of accessors for every different
>>> drm/v4l/etc driver, wouldn't we?
>>
>> Not any more different than you need for this, you just have a new
>> interface that you request a sw object from,
>> then mmap that object, and underneath it knows who owns it in the kernel.
>
> oh, ok, so you are talking about a kernel level interface, rather than
> userspace..
>
> but I guess in this case I don't quite see the difference.  It amounts
> to which fd you call mmap (or ioctl[*]) on..  If you use the dmabuf fd
> directly then you don't have to pass around a 2nd fd.
>
> [*] there is nothing stopping defining some dmabuf ioctls (such as for
> synchronization).. although the thinking was to keep it simple for
> first version of dmabuf
>

Yes a separate kernel level interface.

Well I'd like to keep it even simpler. dmabuf is a buffer sharing API,
shoehorning in a sw mapping API isn't making it simpler.

The problem I have with implementing mmap on the sharing fd, is that
nothing says this should be purely optional and userspace shouldn't
rely on it.

In the Intel GEM space alone you have two types of mapping, one direct
to shmem one via GTT, the GTT could be even be a linear view. The
intel guys initially did GEM mmaps direct to the shmem pages because
it seemed simple, up until they
had to do step two which was do mmaps on the GTT copy and ended up
having two separate mmap methods. I think the problem here is it seems
deceptively simple to add this to the API now because the API is
simple, however I think in the future it'll become a burden that we'll
have to workaround.

Dave.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-10-12 14:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11  9:23 [RFC 0/2] " Sumit Semwal
2011-10-11  9:23 ` [RFC 1/2] dma-buf: " Sumit Semwal
2011-10-12 12:41   ` [Linaro-mm-sig] " Dave Airlie
2011-10-12 13:28     ` Rob Clark
2011-10-12 13:35       ` Dave Airlie
2011-10-12 13:50         ` Rob Clark
2011-10-12 14:01           ` Dave Airlie
2011-10-12 14:24             ` Rob Clark
2011-10-12 14:34               ` Dave Airlie [this message]
2011-10-12 14:49                 ` Daniel Vetter
2011-10-12 15:15                 ` Rob Clark
2011-10-14 10:00   ` Tomasz Stanislawski
2011-10-14 14:13     ` Sumit Semwal
2011-10-14 15:34     ` Rob Clark
2011-10-14 15:35     ` Daniel Vetter
2011-11-03  8:04       ` Marek Szyprowski
2011-11-08 16:59         ` Clark, Rob
2011-11-08 17:42           ` [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanismch Daniel Vetter
2011-11-08 17:55             ` Russell King - ARM Linux
2011-11-08 18:43               ` Daniel Vetter
2011-11-28  7:47                 ` Marek Szyprowski
2011-11-28 10:34                   ` Daniel Vetter
2011-11-25 14:13   ` [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism Dave Airlie
2011-11-25 16:02     ` Daniel Vetter
2011-11-25 16:15   ` Dave Airlie
2011-11-25 16:28     ` Dave Airlie
2011-11-26 14:00       ` Daniel Vetter
2011-11-27  6:59         ` Rob Clark
2011-12-01  5:51           ` Semwal, Sumit
2011-12-01  5:55             ` Semwal, Sumit
2011-10-11  9:23 ` [RFC 2/2] dma-buf: Documentation for buffer sharing framework Sumit Semwal
2011-10-12 22:30   ` Randy Dunlap
2011-10-13  4:48     ` Semwal, Sumit

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='CAPM=9tyAiUZ9tNaer=_52WmiLKpJKG+3EXvZzotwGwvqkJFmOQ@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=arnd@arndb.de \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jesse.barker@linaro.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    --cc=sumit.semwal@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox