Re: [PATCH 1/2] media: v4l: Add Broadcom sand formats to videodev2.h

From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: John Cox <jc@kynesim.co.uk>
Cc: linux-media@vger.kernel.org, hverkuil-cisco@xs4all.nl
Subject: Re: [PATCH 1/2] media: v4l: Add Broadcom sand formats to videodev2.h
Date: Fri, 10 Feb 2023 11:17:23 -0500	[thread overview]
Message-ID: <04dd55039d1c66d382dc9086500e5b8037ed6598.camel@ndufresne.ca> (raw)
In-Reply-To: <1ogauh5ro652so8vtc2fsgor5g3pj6ns3e@4ax.com>

Le jeudi 09 février 2023 à 19:06 +0000, John Cox a écrit :
> Hi
> 
> > Le vendredi 27 janvier 2023 à 15:34 +0000, John Cox a écrit :
> > > Add fourccs for Broadcom 8 and 10-bit packed 128 byte column formats to
> > > videodev2.h
> > > 
> > > Signed-off-by: John Cox <jc@kynesim.co.uk>
> > > ---
> > >  include/uapi/linux/videodev2.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > > index 1befd181a4cc..a836322ae5d8 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -656,6 +656,8 @@ struct v4l2_pix_format {
> > >  #define V4L2_PIX_FMT_P010_4L4 v4l2_fourcc('T', '0', '1', '0') /* 12  Y/CbCr 4:2:0 10-bit 4x4 macroblocks */
> > >  #define V4L2_PIX_FMT_NV12_8L128       v4l2_fourcc('A', 'T', '1', '2') /* Y/CbCr 4:2:0 8x128 tiles */
> > >  #define V4L2_PIX_FMT_NV12_10BE_8L128  v4l2_fourcc_be('A', 'X', '1', '2') /* Y/CbCr 4:2:0 10-bit 8x128 tiles */
> > > +#define V4L2_PIX_FMT_NV12_C128        v4l2_fourcc('C', 'N', '1', '2') /* Y/CbCr 4:2:0 128 byte columns */
> > > +#define V4L2_PIX_FMT_P030_C128        v4l2_fourcc('C', 'N', '3', '0') /* Y/CbCr 4:2:0 10-bit packed 128 byte columns */
> > >  
> > >  /* Tiled YUV formats, non contiguous planes */
> > >  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 tiles */
> > 
> > I would expect updates to v4l2-common.c and v4l2-ioctl.c to be in the same
> > patch. And then the driver should be using the helpers there whenever possible.
> 
> Fair point - I'll fix that.
> 
> What is the correct .bpp for 3 10-bit pixels packed into 4 bytes in the
> v4l2_format_info?

Good question, maybe this can be done with the fractional bpp support. I must
admit, I didn't think about padded cases, I was handling 10bit fully packed over
5 bytes.

https://lore.kernel.org/linux-arm-kernel/20230103170058.810597-3-benjamin.gaignard@collabora.com/
My case ended working with:

 { .format = V4L2_PIX_FMT_NV12_10LE40_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2 },

Question is what do we do about comp_planes, if we kind of fake it to be 2, then maybe this would work.

 { .format = V4L2_PIX_FMT_P030_C128, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 4, 8, 0, 0 }, .bpp_div = { 3, 3, 1, 1 }, .hdiv = 2, .vdiv = 2 },

For weird format, this is a bit of hacky, all we want is to get the right
stride, and the offset part is not used for mem_planes = 1 formats.

let me know,
Nicolas

> 
> Regards
> 
> John Cox