This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter. Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion. Looking forward to meeting in the middle on this!
This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter. Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion. Looking forward to meeting in the middle on this!
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
> wrote:
> > Let's have some competition here for dma_buf mmap support ;-)
> >
> > Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> > and corresponding ioctls on the dma_buf fil
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter wrote:
>> Let's have some competition here for dma_buf mmap support ;-)
>>
>> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
>> and corresponding ioctls on the dma_buf file. The
On Wed, Mar 21, 2012 at 3:25 PM, Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
>> I want to make sure I understand how this would work. I've been planning
>> on making cache maintenance implicit, and most of the corres
be able to fall
> back to coherent mappings.
>
> v2:
> - Spelling fixes from Rob Clark.
> - Compile fix for !DMA_BUF from Rob Clark.
> - Extend commit message to explain how explicitly cache managed mmap
> support could be added later.
> - Extend the documentation wi
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_pla
ter
>
> BR,
> -R
>
> On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin
> wrote:
>> I have a system where the data is planar, but the kernel drivers
>> expect to get one allocation with offsets for the planes. I can't
>> figure out how to do that with the
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to m
es were offsets into the same buffer, to use dma_buf.
Looks like I need to dig a bit deeper.
Thanks,
Rebecca
On Mon, Jun 4, 2012 at 2:58 PM, Hans Verkuil wrote:
> Hi Rebecca,
>
> On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
>> I have a system where the data is planar, bu
be able to fall
> back to coherent mappings.
>
> v2:
> - Spelling fixes from Rob Clark.
> - Compile fix for !DMA_BUF from Rob Clark.
> - Extend commit message to explain how explicitly cache managed mmap
> ?support could be added later.
> - Extend the documentation wi
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_pla
es were offsets into the same buffer, to use dma_buf.
Looks like I need to dig a bit deeper.
Thanks,
Rebecca
On Mon, Jun 4, 2012 at 2:58 PM, Hans Verkuil wrote:
> Hi Rebecca,
>
> On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
>> I have a system where the data is planar, bu
ter
>
> BR,
> -R
>
> On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin
> wrote:
>> I have a system where the data is planar, but the kernel drivers
>> expect to get one allocation with offsets for the planes. ?I can't
>> figure out how to do that with the
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to m
This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter. Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion. Looking forward to meeting in the middle on this!
This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter. Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion. Looking forward to meeting in the middle on this!
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
> wrote:
> > Let's have some competition here for dma_buf mmap support ;-)
> >
> > Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> > and corresponding ioctls on the dma_buf fil
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
> wrote:
>> Let's have some competition here for dma_buf mmap support ;-)
>>
>> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
>> and corresponding ioctls on the dma_buf file. T
On Wed, Mar 21, 2012 at 3:25 PM, Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
>> I want to make sure I understand how this would work. ?I've been planning
>> on making cache maintenance implicit, and most of the corres
20 matches
Mail list logo
