[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131214123709.GE17467@mithrandir>
Date: Sat, 14 Dec 2013 13:37:10 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Thomas Hellstrom <thellstrom@...are.com>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] dma-buf: Implement test module
On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom <thellstrom@...are.com> wrote:
> > On 12/12/2013 03:36 PM, Thierry Reding wrote:
> >>
> >> This is a simple test module that can be used to allocate, export and
> >> delete DMA-BUF objects. It can be used to test DMA-BUF sharing in
> >> systems that lack a real second driver.
> >>
> >>
> >
> > Looks nice. I wonder whether this could be extended to create a "streaming"
> > dma-buf from a user space mapping. That could be used as a generic way to
> > implement streaming (user) buffer objects, rather than to add explicit
> > support for those in, for example, TTM.
>
> Atm there's no way to get gpus to unbind their dma-buf mappings, so
> their essentially pinned forever from first use on.
Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle
returned by drmPrimeFDToHandle()? I mean that should drop the last
reference on the GEM object and cause it to be cleaned up (which should
include detaching the DMA-BUF).
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists