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 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
34 matches
Mail list logo
