[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Rebecca Schultz Zavin]

It probably is a fixed offset, but all the information describing it
is in userspace...  In my experience, it's always almost one of the
pre-defined formats, but then there's some extra padding, weird
alignment etc.  I'm trying to convert code that used userptr, but
where the planes 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 <hverkuil at xs4all.nl> wrote:
> Hi Rebecca,
>
> On Mon June 4 2012 21:34:23 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 current dma_buf implementation.  I
>> thought I could pass the same dma_buf several times and use the
>> data_offset field of the v4l2_plane struct but it looks like that's
>> only for output.  Am I missing something?  Is this supported?
>
> v4l2_plane is typically used if the planes are allocated separately.
> If you allocate it in one go, aren't the planes then at well-defined
> offsets from the start? If so, then it is either one of the already
> pre-defined planar formats found here:
>
> http://hverkuil.home.xs4all.nl/spec/media.html#yuv-formats
>
> or you define a pixelformat specific to your own hardware that identifies
> that particular format.
>
> If it is one allocation, but there is no clear calculation based on width
> and height that gives you the start of each plane, then we do not support
> that at the moment. I believe I had a discussion about something similar
> with people from Qualcomm, but that never came to anything.
>
> That would be something to discuss on the linux-media mailinglist.
>
> Regards,
>
>        Hans