Hi Dave, Daniel, Rob,
>
> On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
>>
>> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
>> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
>> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
>> >> work,
>> >>
>> >> I've
Hi Dave, Daniel, Rob,
On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
> work,
> >>
> >> I've got primed
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 Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
> On Fri, Nov 25, 2011 at 17:28, Dave Airlie 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
On Fri, Nov 25, 2011 at 17:28, Dave Airlie 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 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 Fri, Nov 25, 2011 at 02:13:22PM +, Dave Airlie wrote:
> On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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
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
> +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(>lock);
> +
> + ? ? ?
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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 new
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 Thu, Nov 3, 2011 at 3:04 AM, Marek Szyprowski
wrote:
> Hello,
>
> I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments.
>
> On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote:
>
>> On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
>> > >+/**
>> >
On Thu, Nov 3, 2011 at 3:04 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments.
On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote:
On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
Hello,
I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments.
On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote:
> On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
> > >+/**
> > >+ * struct dma_buf_ops - operations possible on struct dma_buf
> >
Hello,
I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments.
On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote:
On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
+/**
+ * struct dma_buf_ops - operations possible on struct dma_buf
+ *
On 14 October 2011 15:30, Tomasz Stanislawski
wrote:
> Hi Mr. Sumit Semwal,
Hello Mr. Tomasz Stanislawski :),
> Thank you for taking care of the framework for buffer sharing.
> The support of buffer sharing in V4L2, both exporting and importing was
> posted in shrbuf proof-of-concept patch. It
On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
> >+/**
> >+ * struct dma_buf_ops - operations possible on struct dma_buf
> >+ * @create: creates a struct dma_buf of a fixed size. Actual allocation
> >+ * does not happen here.
>
> The 'create' ops is not present in
Hi Mr. Sumit Semwal,
Thank you for taking care of the framework for buffer sharing.
The support of buffer sharing in V4L2, both exporting and importing was
posted in shrbuf proof-of-concept patch. It should be easy to port it to
dmabuf.
On Fri, Oct 14, 2011 at 5:00 AM, Tomasz Stanislawski
wrote:
>> + * @attach: allows different devices to 'attach' themselves to the given
>> + * ? ? ? ? buffer. It might return -EBUSY to signal that backing storage
>> + * ? ? ? ? is already allocated and incompatible with the requirements
>> + * ?
Hi Mr. Sumit Semwal,
Thank you for taking care of the framework for buffer sharing.
The support of buffer sharing in V4L2, both exporting and importing was
posted in shrbuf proof-of-concept patch. It should be easy to port it to
dmabuf.
On 14 October 2011 15:30, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Hi Mr. Sumit Semwal,
Hello Mr. Tomasz Stanislawski :),
Thank you for taking care of the framework for buffer sharing.
The support of buffer sharing in V4L2, both exporting and importing was
posted in shrbuf
On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote:
+/**
+ * struct dma_buf_ops - operations possible on struct dma_buf
+ * @create: creates a struct dma_buf of a fixed size. Actual allocation
+ * does not happen here.
The 'create' ops is not present in dma_buf_ops.
On Fri, Oct 14, 2011 at 5:00 AM, Tomasz Stanislawski
t.stanisl...@samsung.com wrote:
+ * @attach: allows different devices to 'attach' themselves to the given
+ * buffer. It might return -EBUSY to signal that backing storage
+ * is already allocated and incompatible with the
On Wed, Oct 12, 2011 at 03:34:54PM +0100, Dave Airlie wrote:
> On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark wrote:
> > On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie wrote:
> >>> But then we'd need a different set of accessors for every different
> >>> drm/v4l/etc driver, wouldn't we?
> >>
> >> Not
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark wrote:
> On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie 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
>>
> 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
>
> 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
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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 new
On Wed, Oct 12, 2011 at 9:34 AM, Dave Airlie wrote:
> On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark wrote:
>> On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie wrote:
But then we'd need a different set of accessors for every different
drm/v4l/etc driver, wouldn't we?
>>>
>>> Not any more
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie 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
On Wed, Oct 12, 2011 at 8:35 AM, Dave Airlie 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 anyone
On Wed, Oct 12, 2011 at 7:41 AM, Dave Airlie wrote:
> On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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
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
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 new buffer-object to be created with fixed size.
- different devices to 'attach'
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 new buffer-object to be created with fixed size.
- different devices to 'attach'
48 matches
Mail list logo
