Re: [PATCH v6 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Liu Ying <victor.liu@nxp.com>]

Hi Marcel,

On Tue, 2021-03-23 at 00:23 +0000, Marcel Ziswiler wrote:
> On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote:
> > This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
> > and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
> > The RGB pixels with padding low per component are transmitted on a 30-bit
> > input bus(10-bit per component) from a display controller or a 36-bit
> > output bus(12-bit per component) to a pixel link.
> > 
> > Reviewed-by: Robert Foss <robert.foss-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> > Signed-off-by: Liu Ying <victor.liu-3arQi8VN3Tc@public.gmane.org>
> > ---
> > v5->v6:
> > * Add Laurent's R-b tag.
> > 
> > v4->v5:
> > * Add Robert's R-b tag.
> > 
> > v3->v4:
> > * No change.
> > 
> > v2->v3:
> > * No change.
> > 
> > v1->v2:
> > * No change.
> > 
> >  include/uapi/linux/media-bus-format.h | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
> > index 0dfc11e..ec3323d 100644
> > --- a/include/uapi/linux/media-bus-format.h
> > +++ b/include/uapi/linux/media-bus-format.h
> > @@ -34,7 +34,7 @@
> >  
> >  #define MEDIA_BUS_FMT_FIXED                    0x0001
> >  
> > -/* RGB - next is       0x101e */
> > +/* RGB - next is       0x1022 */
> >  #define MEDIA_BUS_FMT_RGB444_1X12              0x1016
> >  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE      0x1001
> >  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE      0x1002
> > @@ -59,9 +59,13 @@
> >  #define MEDIA_BUS_FMT_RGB888_3X8_DELTA         0x101d
> >  #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG                0x1011
> >  #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA       0x1012
> > +#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO       0x101e
> > +#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO       0x101f
> >  #define MEDIA_BUS_FMT_ARGB8888_1X32            0x100d
> >  #define MEDIA_BUS_FMT_RGB888_1X32_PADHI                0x100f
> >  #define MEDIA_BUS_FMT_RGB101010_1X30           0x1018
> > +#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO       0x1020
> > +#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO       0x1021
> >  #define MEDIA_BUS_FMT_RGB121212_1X36           0x1019
> >  #define MEDIA_BUS_FMT_RGB161616_1X48           0x101a
> 
> I haven't figured out what exactly the idea of this strange ordering of things is about? Could you enlighten
> me?

The existing comment in this header file mentions 'The bus formats are
grouped by type, bus_width, bits per component, samples per pixel and
order of subsamples. Numerical values are sorted using
generic numerical sort order (8 thus comes before 10).'

So, the way I read the ordering is that fomarts are first grouped as
'type', like 'RGB', 'YUV'  and 'Bayer', then sorted by 'bus_width',
like '2x8', '1x30' and '1x36', then sorted by 'bits per component',
like 'RGB666', 'RGB888' and 'RGB121212'.

It looks like 'samples per pixel' and 'order of subsamples' are 'YUV'
type relevant.

HTH,
Liu Ying