videobuf2-dma-sg and multiple planes semantics

videobuf2-dma-sg and multiple planes semantics

[Robert Jarzmik]

Hi,

I've been converting pxa_camera driver from videobuf to videobuf2, and I have a
question about multiple plane semantics.

I have a case where I have 3 planes for a yuv422 capture :
 - 1 Y plane (total_size / 2 bytes)
 - 1 U plane (total_size / 4 bytes)
 - 1 V plane (total_size / 4 bytes)

I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
sg_tables, one for each plane. I would have been then able to feed them to 3
dmaengine channels (this is the case for pxa27x platform), so that the 3 planes
are filled in concurrently.

My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems to be
enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and how
do the multiple planes are handled within videobuf2-dma-sg ?

Cheers.

--
Robert

Re: videobuf2-dma-sg and multiple planes semantics

[Robert Jarzmik]

Robert Jarzmik <robert.jarzmik@free.fr> writes:

> Hi,
>
> I've been converting pxa_camera driver from videobuf to videobuf2, and I have a
> question about multiple plane semantics.
>
> I have a case where I have 3 planes for a yuv422 capture :
>  - 1 Y plane (total_size / 2 bytes)
>  - 1 U plane (total_size / 4 bytes)
>  - 1 V plane (total_size / 4 bytes)
>
> I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
> sg_tables, one for each plane. I would have been then able to feed them to 3
> dmaengine channels (this is the case for pxa27x platform), so that the 3 planes
> are filled in concurrently.
>
> My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems to be
> enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and how
> do the multiple planes are handled within videobuf2-dma-sg ?

Oh I think I was a bit mislead, because I was looking at it from a userspace
perspective. The in-kernel pxa_camera has 3 different sg_tables all right.

The issue is rather that from userspace, the call to VIDIOC_QUERYBUF, which is
an old userspace program (such as capture_example.c, year 2008 version), returns
only half of the total_size.

Now looking at it more closely, I think this is because :
 - in videobuf2-v4l2.c
 - as my old program doesn't set the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE bit
 - __fill_v4l2_buffer() returns b->length = vb->planes[0].length

I would have expected to have b->length = sum(vb->planes[i].length).

Could someone explain to me the rationale behind returning only the first plane
length instead of the sum of all planes lengthes ?

Cheers.

-- 
Robert

Re: videobuf2-dma-sg and multiple planes semantics

[Hans Verkuil]

Hi Robert,

On 03/07/16 19:08, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
> 
>> Hi,
>>
>> I've been converting pxa_camera driver from videobuf to videobuf2, and I have a
>> question about multiple plane semantics.
>>
>> I have a case where I have 3 planes for a yuv422 capture :
>>  - 1 Y plane (total_size / 2 bytes)
>>  - 1 U plane (total_size / 4 bytes)
>>  - 1 V plane (total_size / 4 bytes)
>>
>> I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
>> sg_tables, one for each plane. I would have been then able to feed them to 3
>> dmaengine channels (this is the case for pxa27x platform), so that the 3 planes
>> are filled in concurrently.
>>
>> My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems to be
>> enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and how
>> do the multiple planes are handled within videobuf2-dma-sg ?
> 
> Oh I think I was a bit mislead, because I was looking at it from a userspace
> perspective. The in-kernel pxa_camera has 3 different sg_tables all right.
> 
> The issue is rather that from userspace, the call to VIDIOC_QUERYBUF, which is
> an old userspace program (such as capture_example.c, year 2008 version), returns
> only half of the total_size.
> 
> Now looking at it more closely, I think this is because :
>  - in videobuf2-v4l2.c
>  - as my old program doesn't set the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE bit
>  - __fill_v4l2_buffer() returns b->length = vb->planes[0].length
> 
> I would have expected to have b->length = sum(vb->planes[i].length).
> 
> Could someone explain to me the rationale behind returning only the first plane
> length instead of the sum of all planes lengthes ?

I think the cause of your confusion is what 'multi-planar' means in the v4l2 context.
The multi-planar formats are formats that have more than one plane where each plane
can be anywhere in memory. So two or three buffers are allocated separately and
each buffer has its own sglist (setup by vb2).

In the case of PIX_FMT_YUV422P there is only *one* buffer and the planes are laid out in
that single buffer. So from the point of view of v4l2/vb2 this is a single planar
format and you have a single sglist.

You'll have to use sg_split() to split up that single large sglist into three, one for
each channel.

An alternative might be to switch to use V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and use
V4L2_PIX_FMT_YUV422M instead of PIX_FMT_YUV422P, but that would affect existing
applications that expect single planar formats and I cannot recommend this.

Especially since the sg_split function already exists, so it is not hard to split
the single sglist into three.

Regards,

	Hans

Re: videobuf2-dma-sg and multiple planes semantics

[Robert Jarzmik]

Hans Verkuil <hverkuil@xs4all.nl> writes:

> Hi Robert,
>
> In the case of PIX_FMT_YUV422P there is only *one* buffer and the planes are laid out in
> that single buffer. So from the point of view of v4l2/vb2 this is a single planar
> format and you have a single sglist.h
That's the piece of information I was missing, thanks.

> You'll have to use sg_split() to split up that single large sglist into three, one for
> each channel.
Yeah, being the author of it, I should be able to use it again :)

Cheers.

--
Robert