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 gea
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 gea
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 rul
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 rul
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).
>
> http://cgi
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).
>
> http://cgi
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 buffer
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 t
> +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);
> +
> + ? ?
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 buffer-obje
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 t
> +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);
> +
> +
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 buffer
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 buffer-obje
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
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 s
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_bu
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.
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August
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
>> + * ?
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
>> + *
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_bu
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 sh
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.
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-Augu
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 a
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
>> interfac
> 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 j
>
> 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 want
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 buffer-obje
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 diffe
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 obje
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 e
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 acro
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 diffe
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 a
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
>> interfac
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 obje
> 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 j
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 e
>
> 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 want
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 acro
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 buffer-obje
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' t
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' t
48 matches
Mail list logo
