Robert Jarzmik <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
