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@xxxxxxxxxxxxxxxx> > > Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@xxxxxxxxxxxxxxxx> > > Signed-off-by: Liu Ying <victor.liu-3arQi8VN3Tc@xxxxxxxxxxxxxxxx> > > --- > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
