diff mbox series

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

Message ID 1615952569-4711-2-git-send-email-victor.liu@nxp.com (mailing list archive)
State New, archived
Headers show
Series Add some DRM bridge drivers support for i.MX8qm/qxp SoCs | expand

Commit Message

Liu Ying March 17, 2021, 3:42 a.m. UTC 
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@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
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(-)

Comments

Marcel Ziswiler March 23, 2021, 12:23 a.m. UTC | #1 
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?
Liu Ying March 23, 2021, 3 a.m. UTC | #2 
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
diff mbox series

Patch

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