Hi Dave, Daniel, Rob,
On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark robdcl...@gmail.com wrote:
On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Nov 25, 2011 at 17:28, Dave Airlie airl...@gmail.com wrote:
I've rebuilt my PRIME interface on top of dmabuf to see how
Hi Dave, Daniel, Rob,
On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark robdcl...@gmail.com wrote:
On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Nov 25, 2011 at 17:28, Dave Airlie airl...@gmail.com wrote:
I've rebuilt my PRIME interface on top of dmabuf to see how
On Fri, Nov 25, 2011 at 17:28, Dave Airlie airl...@gmail.com wrote:
I've rebuilt my PRIME interface on top of dmabuf to see how it would work,
I've got primed gears running again on top, but I expect all my object
lifetime and memory ownership rules need fixing up (i.e. leaks like a
sieve).
On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Nov 25, 2011 at 17:28, Dave Airlie airl...@gmail.com wrote:
I've rebuilt my PRIME interface on top of dmabuf to see how it would work,
I've got primed gears running again on top, but I expect all my object
lifetime
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- a
On Fri, Nov 25, 2011 at 02:13:22PM +, Dave Airlie wrote:
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of
+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+ struct dma_buf_attachment *attach;
+ int ret;
+
+ BUG_ON(!dmabuf || !dev);
+
+ mutex_lock(dmabuf-lock);
+
+ attach =
I've rebuilt my PRIME interface on top of dmabuf to see how it would work,
I've got primed gears running again on top, but I expect all my object
lifetime and memory ownership rules need fixing up (i.e. leaks like a
sieve).
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf
has
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- a
On Wed, Oct 12, 2011 at 7:41 AM, Dave Airlie airl...@gmail.com wrote:
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
well, the mmap is actually implemented by the buffer allocator
(v4l/drm).. although not sure if this was the point
Then why not use the correct interface? doing some sort of not-quite
generic interface isn't really helping anyone except adding an ABI
that we have to support.
If someone wants
On Wed, Oct 12, 2011 at 8:35 AM, Dave Airlie airl...@gmail.com wrote:
well, the mmap is actually implemented by the buffer allocator
(v4l/drm).. although not sure if this was the point
Then why not use the correct interface? doing some sort of not-quite
generic interface isn't really helping
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.
mmap
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@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
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@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
On Wed, Oct 12, 2011 at 03:34:54PM +0100, Dave Airlie wrote:
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote:
But then we'd need a different set of accessors for every different
drm/v4l/etc driver,
On Wed, Oct 12, 2011 at 9:34 AM, Dave Airlie airl...@gmail.com wrote:
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote:
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote:
But then we'd need a different set of accessors for every different
drm/v4l/etc
17 matches
Mail list logo
