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