[PATCH v2 0/7] media/drm: renesas: Add new pixel formats

[PATCH v2 0/7] media/drm: renesas: Add new pixel formats

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

Hi,

These add new pixel formats for Renesas V3U and V4H SoCs.

As the display pipeline is split between DRM and V4L2 components, this
series touches both subsystems. I'm sending all these together to
simplify review. If needed, I can later split this to V4L2 and DRM
parts, of which the V4L2 part needs to be merged first.

Changes in v2:

- Add kernel documentation for the new formats
- Add PACK_CPOS & PACK_CLEN macros for writing to ext_infmt registers
- Fix wrong alpha component values in ext_infmt registers

 Tomi

Tomi Valkeinen (7):
  media: Add 2-10-10-10 RGB formats
  media: Add Y210, Y212 and Y216 formats
  media: renesas: vsp1: Change V3U to be gen4
  media: renesas: vsp1: Add V4H SoC version
  media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)
  drm: rcar-du: Bump V3U to gen 4
  drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

 .../media/v4l/pixfmt-packed-yuv.rst           |  44 ++++
 .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c         |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c         |  24 +++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c         |  49 ++++-
 .../media/platform/renesas/vsp1/vsp1_drv.c    |   4 +-
 .../media/platform/renesas/vsp1/vsp1_hgo.c    |   4 +-
 .../media/platform/renesas/vsp1/vsp1_lif.c    |   1 +
 .../media/platform/renesas/vsp1/vsp1_pipe.c   |  15 ++
 .../media/platform/renesas/vsp1/vsp1_regs.h   |  25 ++-
 .../media/platform/renesas/vsp1/vsp1_rpf.c    |  61 +++++-
 .../media/platform/renesas/vsp1/vsp1_video.c  |   4 +-
 .../media/platform/renesas/vsp1/vsp1_wpf.c    |   4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c          |   6 +
 include/uapi/linux/videodev2.h                |  11 +
 15 files changed, 430 insertions(+), 18 deletions(-)

-- 
2.34.1

[PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Tomi Valkeinen]

Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
 drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
 include/uapi/linux/videodev2.h                |   3 +
 3 files changed, 200 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 30f51cd33f99..de78cd2dcd73 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
     \normalsize
 
 
+10 Bits Per Component
+=====================
+
+These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
+bytes. They are named based on the order of the RGB components as seen in a
+32-bit word, which is then stored in memory in little endian byte order
+(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
+number of bits for each component.
+
+.. raw:: latex
+
+    \begingroup
+    \tiny
+    \setlength{\tabcolsep}{2pt}
+
+.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+
+.. flat-table:: RGB Formats 10 Bits Per Color Component
+    :header-rows:  2
+    :stub-columns: 0
+
+    * - Identifier
+      - Code
+      - :cspan:`7` Byte 0 in memory
+      - :cspan:`7` Byte 1
+      - :cspan:`7` Byte 2
+      - :cspan:`7` Byte 3
+    * -
+      -
+      - 7
+      - 6
+      - 5
+      - 4
+      - 3
+      - 2
+      - 1
+      - 0
+
+      - 7
+      - 6
+      - 5
+      - 4
+      - 3
+      - 2
+      - 1
+      - 0
+
+      - 7
+      - 6
+      - 5
+      - 4
+      - 3
+      - 2
+      - 1
+      - 0
+
+      - 7
+      - 6
+      - 5
+      - 4
+      - 3
+      - 2
+      - 1
+      - 0
+    * .. _V4L2-PIX-FMT-XBGR2101010:
+
+      - ``V4L2_PIX_FMT_XBGR2101010``
+      - 'RX30'
+
+      - b\ :sub:`5`
+      - b\ :sub:`4`
+      - b\ :sub:`3`
+      - b\ :sub:`2`
+      - b\ :sub:`1`
+      - b\ :sub:`0`
+      - x
+      - x
+
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
+      - b\ :sub:`9`
+      - b\ :sub:`8`
+      - b\ :sub:`7`
+      - b\ :sub:`6`
+
+      - r\ :sub:`1`
+      - r\ :sub:`0`
+      - g\ :sub:`9`
+      - g\ :sub:`8`
+      - g\ :sub:`7`
+      - g\ :sub:`6`
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+
+      - r\ :sub:`9`
+      - r\ :sub:`8`
+      - r\ :sub:`7`
+      - r\ :sub:`6`
+      - r\ :sub:`5`
+      - r\ :sub:`4`
+      - r\ :sub:`3`
+      - r\ :sub:`2`
+      -
+    * .. _V4L2-PIX-FMT-ABGR2101010:
+
+      - ``V4L2_PIX_FMT_ABGR2101010``
+      - 'RA30'
+
+      - b\ :sub:`5`
+      - b\ :sub:`4`
+      - b\ :sub:`3`
+      - b\ :sub:`2`
+      - b\ :sub:`1`
+      - b\ :sub:`0`
+      - a\ :sub:`1`
+      - a\ :sub:`0`
+
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
+      - b\ :sub:`9`
+      - b\ :sub:`8`
+      - b\ :sub:`7`
+      - b\ :sub:`6`
+
+      - r\ :sub:`1`
+      - r\ :sub:`0`
+      - g\ :sub:`9`
+      - g\ :sub:`8`
+      - g\ :sub:`7`
+      - g\ :sub:`6`
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+
+      - r\ :sub:`9`
+      - r\ :sub:`8`
+      - r\ :sub:`7`
+      - r\ :sub:`6`
+      - r\ :sub:`5`
+      - r\ :sub:`4`
+      - r\ :sub:`3`
+      - r\ :sub:`2`
+      -
+    * .. _V4L2-PIX-FMT-BGRA1010102:
+
+      - ``V4L2_PIX_FMT_BGRA1010102``
+      - 'AR30'
+
+      - b\ :sub:`7`
+      - b\ :sub:`6`
+      - b\ :sub:`5`
+      - b\ :sub:`4`
+      - b\ :sub:`3`
+      - b\ :sub:`2`
+      - b\ :sub:`1`
+      - b\ :sub:`0`
+
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
+      - b\ :sub:`9`
+      - b\ :sub:`8`
+
+      - r\ :sub:`3`
+      - r\ :sub:`2`
+      - r\ :sub:`1`
+      - r\ :sub:`0`
+      - g\ :sub:`9`
+      - g\ :sub:`8`
+      - g\ :sub:`7`
+      - g\ :sub:`6`
+
+      - a\ :sub:`1`
+      - a\ :sub:`0`
+      - r\ :sub:`9`
+      - r\ :sub:`8`
+      - r\ :sub:`7`
+      - r\ :sub:`6`
+      - r\ :sub:`5`
+      - r\ :sub:`4`
+      -
+
+.. raw:: latex
+
+    \endgroup
+
+
 Deprecated RGB Formats
 ======================
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index fddba75d9074..964300deaf62 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 	case V4L2_PIX_FMT_BGRX32:	descr = "32-bit XBGR 8-8-8-8"; break;
 	case V4L2_PIX_FMT_RGBA32:	descr = "32-bit RGBA 8-8-8-8"; break;
 	case V4L2_PIX_FMT_RGBX32:	descr = "32-bit RGBX 8-8-8-8"; break;
+	case V4L2_PIX_FMT_XBGR2101010:	descr = "32-bit XBGR 2-10-10-10"; break;
+	case V4L2_PIX_FMT_ABGR2101010:	descr = "32-bit ABGR 2-10-10-10"; break;
+	case V4L2_PIX_FMT_BGRA1010102:	descr = "32-bit BGRA 10-10-10-2"; break;
 	case V4L2_PIX_FMT_GREY:		descr = "8-bit Greyscale"; break;
 	case V4L2_PIX_FMT_Y4:		descr = "4-bit Greyscale"; break;
 	case V4L2_PIX_FMT_Y6:		descr = "6-bit Greyscale"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 29da1f4b4578..877fd61693b8 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -576,6 +576,9 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_RGBX32  v4l2_fourcc('X', 'B', '2', '4') /* 32  RGBX-8-8-8-8  */
 #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  ARGB-8-8-8-8  */
 #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  XRGB-8-8-8-8  */
+#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('R', 'X', '3', '0') /* 32  XBGR-2-10-10-10  */
+#define V4L2_PIX_FMT_ABGR2101010 v4l2_fourcc('R', 'A', '3', '0') /* 32  ABGR-2-10-10-10  */
+#define V4L2_PIX_FMT_BGRA1010102 v4l2_fourcc('A', 'R', '3', '0') /* 32  BGRA-10-10-10-2  */
 
 /* Grey formats */
 #define V4L2_PIX_FMT_GREY    v4l2_fourcc('G', 'R', 'E', 'Y') /*  8  Greyscale     */
-- 
2.34.1

[PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats

[Tomi Valkeinen]

Add Y210, Y212 and Y216 formats.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 .../media/v4l/pixfmt-packed-yuv.rst           | 44 +++++++++++++++++++
 drivers/media/v4l2-core/v4l2-ioctl.c          |  3 ++
 include/uapi/linux/videodev2.h                |  8 ++++
 3 files changed, 55 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
index bf283a1b5581..3f193e5fd5cb 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
@@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4 bytes.
       - Y'\ :sub:`3`
       - Cb\ :sub:`2`
 
+The packed YUYV formats with more than 8 bits per component are stored as four
+16-bit little-endian words. Each word's most significat bits contain one
+component, and the least significant bits are zero padding.
+
+.. tabularcolumns:: |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
+
+.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
+    :header-rows: 1
+    :stub-columns: 0
+
+    * - Identifier
+      - Code
+      - Word 0
+      - Word 1
+      - Word 2
+      - Word 3
+    * .. _V4L2-PIX-FMT-Y210:
+
+      - ``V4L2_PIX_FMT_Y210``
+      - 'Y210'
+
+      - Y'\ :sub:`0` (bits 15-6)
+      - Cb\ :sub:`0` (bits 15-6)
+      - Y'\ :sub:`1` (bits 15-6)
+      - Cr\ :sub:`0` (bits 15-6)
+    * .. _V4L2-PIX-FMT-Y212:
+
+      - ``V4L2_PIX_FMT_Y212``
+      - 'Y212'
+
+      - Y'\ :sub:`0` (bits 15-4)
+      - Cb\ :sub:`0` (bits 15-4)
+      - Y'\ :sub:`1` (bits 15-4)
+      - Cr\ :sub:`0` (bits 15-4)
+    * .. _V4L2-PIX-FMT-Y216:
+
+      - ``V4L2_PIX_FMT_Y216``
+      - 'Y216'
+
+      - Y'\ :sub:`0` (bits 15-0)
+      - Cb\ :sub:`0` (bits 15-0)
+      - Y'\ :sub:`1` (bits 15-0)
+      - Cr\ :sub:`0` (bits 15-0)
+
 .. raw:: latex
 
     \normalsize
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 964300deaf62..ba95389a59b5 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 	case V4L2_META_FMT_RK_ISP1_STAT_3A:	descr = "Rockchip ISP1 3A Statistics"; break;
 	case V4L2_PIX_FMT_NV12M_8L128:	descr = "NV12M (8x128 Linear)"; break;
 	case V4L2_PIX_FMT_NV12M_10BE_8L128:	descr = "10-bit NV12M (8x128 Linear, BE)"; break;
+	case V4L2_PIX_FMT_Y210:		descr = "10-bit YUYV Packed"; break;
+	case V4L2_PIX_FMT_Y212:		descr = "12-bit YUYV Packed"; break;
+	case V4L2_PIX_FMT_Y216:		descr = "16-bit YUYV Packed"; break;
 
 	default:
 		/* Compressed formats */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 877fd61693b8..15b640d2da8a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -621,6 +621,14 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_YUVX32  v4l2_fourcc('Y', 'U', 'V', 'X') /* 32  YUVX-8-8-8-8  */
 #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
 
+/*
+ * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy the MSBs
+ * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
+ */
+#define V4L2_PIX_FMT_Y210    v4l2_fourcc('Y', '2', '1', '0') /* 32  YUYV 4:2:2 */
+#define V4L2_PIX_FMT_Y212    v4l2_fourcc('Y', '2', '1', '2') /* 32  YUYV 4:2:2 */
+#define V4L2_PIX_FMT_Y216    v4l2_fourcc('Y', '2', '1', '6') /* 32  YUYV 4:2:2 */
+
 /* two planes -- one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
 #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */
-- 
2.34.1

[PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Tomi Valkeinen]

V3U is actually gen4, not gen3. The same IP is also used in the
(not-yet-supported) V4H.

Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
to represent the model correctly. V3U and V4H can still be
differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.

Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
and update the code to correcly match for gen 4.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
 drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
 drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
 drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
 drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
 drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
 drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
 7 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
index c260d318d298..5710152d6511 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
@@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
 		.wpf_count = 2,
 		.num_bru_inputs = 5,
 	}, {
-		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
+		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
 		.model = "VSP2-D",
-		.gen = 3,
+		.gen = 4,
 		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
 		.lif_count = 1,
 		.rpf_count = 5,
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
index bf3f981f93a1..e6492deb0a64 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
@@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
 
 	/* Initialize the control handler. */
 	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
-			       vsp1->info->gen == 3 ? 2 : 1);
+			       vsp1->info->gen >= 3 ? 2 : 1);
 	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
 						  &hgo_max_rgb_control, NULL);
-	if (vsp1->info->gen == 3)
+	if (vsp1->info->gen >= 3)
 		hgo->ctrls.num_bins =
 			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
 					     &hgo_num_bins_control, NULL);
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
index 186a5730e1e3..0ab2e0c70474 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
@@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
 		break;
 
 	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
+	case VI6_IP_VERSION_MODEL_VSPD_GEN4:
 	default:
 		hbth = 0;
 		obth = 3000;
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index 8928f4c6bb55..8c9333f76858 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -766,7 +766,7 @@
 #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
 #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
 #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
-#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
+#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
 /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
 #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
 
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 75083cb234fe..045aa54f7998 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
 	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
 	 * otherwise.
 	 *
-	 * The Gen3 RPF has extended alpha capability and can both multiply the
+	 * The Gen3+ RPF has extended alpha capability and can both multiply the
 	 * alpha channel by a fixed global alpha value, and multiply the pixel
 	 * components to convert the input to premultiplied alpha.
 	 *
 	 * As alpha premultiplication is available in the BRx for both Gen2 and
-	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
+	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
 	 * alpha multiplication only. This however prevents conversion to
 	 * premultiplied alpha if no BRx is present in the pipeline. If that use
 	 * case turns out to be useful we will revisit the implementation (for
 	 * Gen3 only).
 	 *
-	 * We enable alpha multiplication on Gen3 using the fixed alpha value
+	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
 	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
 	 * contains an alpha channel. On Gen2 the global alpha is ignored in
 	 * that case.
@@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
 		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
 				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
 
-	if (entity->vsp1->info->gen == 3) {
+	if (entity->vsp1->info->gen >= 3) {
 		u32 mult;
 
 		if (fmtinfo->alpha) {
@@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
 	}
 
 	/*
-	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
+	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
 	 * formats. Swap the U and V planes manually in that case.
 	 */
-	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
+	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
 	    fmtinfo->swap_uv)
 		swap(mem.addr[1], mem.addr[2]);
 
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
index 9d24647c8f32..544012fd1fe9 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
@@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
 	div_size = format->width;
 
 	/*
-	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
+	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
 	 * with a single partition that covers the whole output.
 	 */
-	if (vsp1->info->gen == 3) {
+	if (vsp1->info->gen >= 3) {
 		list_for_each_entry(entity, &pipe->entities, list_pipe) {
 			unsigned int entity_max;
 
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
index 94e91d7bb56c..d0074ca00920 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
@@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
 	}
 
 	/*
-	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
+	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
 	 * formats. Swap the U and V planes manually in that case.
 	 */
-	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
+	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
 	    fmtinfo->swap_uv)
 		swap(mem.addr[1], mem.addr[2]);
 
-- 
2.34.1

[PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version

[Tomi Valkeinen]

Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index 8c9333f76858..c61e8dafeecf 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -782,6 +782,7 @@
 #define VI6_IP_VERSION_SOC_M3N		(0x04 << 0)
 #define VI6_IP_VERSION_SOC_E3		(0x04 << 0)
 #define VI6_IP_VERSION_SOC_V3U		(0x05 << 0)
+#define VI6_IP_VERSION_SOC_V4H		(0x06 << 0)
 /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification */
 #define VI6_IP_VERSION_SOC_RZG2L	(0x80 << 0)
 
-- 
2.34.1

[PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)

[Tomi Valkeinen]

Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 .../media/platform/renesas/vsp1/vsp1_pipe.c   | 15 ++++++
 .../media/platform/renesas/vsp1/vsp1_regs.h   | 22 +++++++++
 .../media/platform/renesas/vsp1/vsp1_rpf.c    | 49 +++++++++++++++++++
 3 files changed, 86 insertions(+)

diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
index f72ac01c21ea..2867b3de06fa 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
@@ -146,6 +146,18 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
 	  VI6_FMT_ARGB_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
 	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
 	  1, { 32, 0, 0 }, false, false, 1, 1, false },
+	{ V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
+	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
+	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+	  1, { 32, 0, 0 }, false, false, 1, 1, false },
+	{ V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
+	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
+	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+	  1, { 32, 0, 0 }, false, false, 1, 1, false },
+	{ V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB8888_1X32,
+	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
+	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+	  1, { 32, 0, 0 }, false, false, 1, 1, false },
 	{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
 	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
 	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
@@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
 	  VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
 	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
 	  3, { 8, 8, 8 }, false, true, 1, 1, false },
+	{ V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
+	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
+	  1, { 32, 0, 0 }, false, false, 2, 1, false },
 };
 
 /**
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
index c61e8dafeecf..8947ea05f95e 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
@@ -228,6 +228,27 @@
 #define VI6_RPF_MULT_ALPHA_RATIO_MASK	(0xff << 0)
 #define VI6_RPF_MULT_ALPHA_RATIO_SHIFT	0
 
+#define VI6_RPF_EXT_INFMT0		0x0370
+#define VI6_RPF_EXT_INFMT0_F2B_LSB		(0 << 12)
+#define VI6_RPF_EXT_INFMT0_F2B_MSB		(1 << 12)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_8		(0 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_10		(1 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_Y_12		(2 << 8)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_8		(0 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_10		(1 << 4)
+#define VI6_RPF_EXT_INFMT0_IPBD_C_12		(2 << 4)
+#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10	(3 << 0)
+#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10	(0 << 0)
+
+#define VI6_RPF_EXT_INFMT1		0x0374
+#define VI6_RPF_EXT_INFMT2		0x0378
+
+#define VI6_RPF_BRDITH_CTRL		0x03e0
+#define VI6_RPF_BRDITH_CTRL_ODE_EN	(1 << 8)
+#define VI6_RPF_BRDITH_CTRL_ODE_DIS	(0 << 8)
+#define VI6_RPF_BRDITH_CTRL_CBRM_RO	(1 << 0)
+#define VI6_RPF_BRDITH_CTRL_CBRM_TR	(0 << 0)
+
 /* -----------------------------------------------------------------------------
  * WPF Control Registers
  */
@@ -846,6 +867,7 @@
 #define VI6_FMT_XBXGXR_262626		0x21
 #define VI6_FMT_ABGR_8888		0x22
 #define VI6_FMT_XXRGB_88565		0x23
+#define VI6_FMT_RGB10_RGB10A2_A2RGB10	0x30
 
 #define VI6_FMT_Y_UV_444		0x40
 #define VI6_FMT_Y_UV_422		0x41
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
index 045aa54f7998..60ba3c62e86c 100644
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
@@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
  * VSP1 Entity Operations
  */
 
+#define PACK_CPOS(a, b, c, d) \
+	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+#define PACK_CLEN(a, b, c, d) \
+	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
+
 static void rpf_configure_stream(struct vsp1_entity *entity,
 				 struct vsp1_pipeline *pipe,
 				 struct vsp1_dl_list *dl,
@@ -109,6 +114,50 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
 	vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
 	vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
 
+	if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) == VI6_IP_VERSION_MODEL_VSPD_GEN4) {
+		u32 ext_infmt0;
+		u32 ext_infmt1;
+		u32 ext_infmt2;
+
+		switch (fmtinfo->fourcc) {
+		case V4L2_PIX_FMT_XBGR2101010:
+			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
+			ext_infmt1 = PACK_CPOS(0, 10, 20, 0);
+			ext_infmt2 = PACK_CLEN(10, 10, 10, 0);
+			break;
+
+		case V4L2_PIX_FMT_ABGR2101010:
+			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
+			ext_infmt1 = PACK_CPOS(0, 10, 20, 30);
+			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
+			break;
+
+		case V4L2_PIX_FMT_BGRA1010102:
+			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
+			ext_infmt1 = PACK_CPOS(2, 12, 22, 0);
+			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
+			break;
+
+		case V4L2_PIX_FMT_Y210:
+			ext_infmt0 = VI6_RPF_EXT_INFMT0_F2B_MSB |
+				     VI6_RPF_EXT_INFMT0_IPBD_Y_10 |
+				     VI6_RPF_EXT_INFMT0_IPBD_C_10;
+			ext_infmt1 = 0x0;
+			ext_infmt2 = 0x0;
+			break;
+
+		default:
+			ext_infmt0 = 0;
+			ext_infmt1 = 0;
+			ext_infmt2 = 0;
+			break;
+		}
+
+		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT0, ext_infmt0);
+		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT1, ext_infmt1);
+		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT2, ext_infmt2);
+	}
+
 	/* Output location. */
 	if (pipe->brx) {
 		const struct v4l2_rect *compose;
-- 
2.34.1

[PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

[Tomi Valkeinen]

V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
rcar_du_r8a779a0_info.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 46c60a2d710d..c7c5217cfc1a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -504,7 +504,7 @@ static const struct rcar_du_device_info rcar_du_r8a7799x_info = {
 };
 
 static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
-	.gen = 3,
+	.gen = 4,
 	.features = RCAR_DU_FEATURE_CRTC_IRQ
 		  | RCAR_DU_FEATURE_VSP1_SOURCE
 		  | RCAR_DU_FEATURE_NO_BLENDING,
-- 
2.34.1

[PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Tomi Valkeinen]

Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
 2 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 8c2719efda2a..8ccabf5a30c4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
 		.bpp = 32,
 		.planes = 1,
 		.hsub = 1,
+	}, {
+		.fourcc = DRM_FORMAT_RGBX1010102,
+		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
+		.bpp = 32,
+		.planes = 1,
+		.hsub = 1,
+	}, {
+		.fourcc = DRM_FORMAT_RGBA1010102,
+		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
+		.bpp = 32,
+		.planes = 1,
+		.hsub = 1,
+	}, {
+		.fourcc = DRM_FORMAT_ARGB2101010,
+		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
+		.bpp = 32,
+		.planes = 1,
+		.hsub = 1,
 	}, {
 		.fourcc = DRM_FORMAT_YVYU,
 		.v4l2 = V4L2_PIX_FMT_YVYU,
@@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
 		.bpp = 24,
 		.planes = 3,
 		.hsub = 1,
+	}, {
+		.fourcc = DRM_FORMAT_Y210,
+		.v4l2 = V4L2_PIX_FMT_Y210,
+		.bpp = 32,
+		.planes = 1,
+		.hsub = 2,
 	},
 };
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e465aef41585..6f3e109a4f80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
 	DRM_FORMAT_YVU444,
 };
 
+/*
+ * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
+ * formats and Y210 format.
+ */
+static const u32 rcar_du_vsp_formats_gen4[] = {
+	DRM_FORMAT_RGB332,
+	DRM_FORMAT_ARGB4444,
+	DRM_FORMAT_XRGB4444,
+	DRM_FORMAT_ARGB1555,
+	DRM_FORMAT_XRGB1555,
+	DRM_FORMAT_RGB565,
+	DRM_FORMAT_BGR888,
+	DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGRA8888,
+	DRM_FORMAT_BGRX8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_RGBX1010102,
+	DRM_FORMAT_RGBA1010102,
+	DRM_FORMAT_ARGB2101010,
+	DRM_FORMAT_UYVY,
+	DRM_FORMAT_YUYV,
+	DRM_FORMAT_YVYU,
+	DRM_FORMAT_NV12,
+	DRM_FORMAT_NV21,
+	DRM_FORMAT_NV16,
+	DRM_FORMAT_NV61,
+	DRM_FORMAT_YUV420,
+	DRM_FORMAT_YVU420,
+	DRM_FORMAT_YUV422,
+	DRM_FORMAT_YVU422,
+	DRM_FORMAT_YUV444,
+	DRM_FORMAT_YVU444,
+	DRM_FORMAT_Y210,
+};
+
 static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
 {
 	struct rcar_du_vsp_plane_state *state =
@@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
 					 ? DRM_PLANE_TYPE_PRIMARY
 					 : DRM_PLANE_TYPE_OVERLAY;
 		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
+		unsigned int num_formats;
+		const u32 *formats;
+
+		if (rcdu->info->gen < 4) {
+			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
+			formats = rcar_du_vsp_formats;
+		} else {
+			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
+			formats = rcar_du_vsp_formats_gen4;
+		}
 
 		plane->vsp = vsp;
 		plane->index = i;
 
 		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
 					       crtcs, &rcar_du_vsp_plane_funcs,
-					       rcar_du_vsp_formats,
-					       ARRAY_SIZE(rcar_du_vsp_formats),
+					       formats, num_formats,
 					       NULL, type, NULL);
 		if (ret < 0)
 			return ret;
-- 
2.34.1

Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

[Kieran Bingham]

Quoting Tomi Valkeinen (2022-12-19 14:01:38)
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the

s/Bumb/bump/

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

> rcar_du_r8a779a0_info.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info rcar_du_r8a7799x_info = {
>  };
>  
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> -       .gen = 3,
> +       .gen = 4,
>         .features = RCAR_DU_FEATURE_CRTC_IRQ
>                   | RCAR_DU_FEATURE_VSP1_SOURCE
>                   | RCAR_DU_FEATURE_NO_BLENDING,
> -- 
> 2.34.1
>

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>  drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>  include/uapi/linux/videodev2.h                |   3 +
>  3 files changed, 200 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> index 30f51cd33f99..de78cd2dcd73 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>      \normalsize
>  
>  
> +10 Bits Per Component
> +=====================
> +
> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> +bytes. They are named based on the order of the RGB components as seen in a
> +32-bit word, which is then stored in memory in little endian byte order
> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
> +number of bits for each component.
> +
> +.. raw:: latex
> +
> +    \begingroup
> +    \tiny
> +    \setlength{\tabcolsep}{2pt}
> +
> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> +
> +
> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> +    :header-rows:  2
> +    :stub-columns: 0
> +
> +    * - Identifier
> +      - Code
> +      - :cspan:`7` Byte 0 in memory
> +      - :cspan:`7` Byte 1
> +      - :cspan:`7` Byte 2
> +      - :cspan:`7` Byte 3
> +    * -
> +      -
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +    * .. _V4L2-PIX-FMT-XBGR2101010:
> +
> +      - ``V4L2_PIX_FMT_XBGR2101010``
> +      - 'RX30'
> +
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +      - x
> +      - x
> +
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      -

This doesn't match the text above. This would be RGBX2101010. I'm not
sure which format you want, so I don't know if it's the documentation or
the format name that is incorrect. The next two formats also seem
incorrect to me.

> +    * .. _V4L2-PIX-FMT-ABGR2101010:
> +
> +      - ``V4L2_PIX_FMT_ABGR2101010``
> +      - 'RA30'
> +
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +      - a\ :sub:`1`
> +      - a\ :sub:`0`
> +
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      -
> +    * .. _V4L2-PIX-FMT-BGRA1010102:
> +
> +      - ``V4L2_PIX_FMT_BGRA1010102``
> +      - 'AR30'
> +
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +
> +      - a\ :sub:`1`
> +      - a\ :sub:`0`
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      -
> +
> +.. raw:: latex
> +
> +    \endgroup
> +
> +
>  Deprecated RGB Formats
>  ======================
>  
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index fddba75d9074..964300deaf62 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  	case V4L2_PIX_FMT_BGRX32:	descr = "32-bit XBGR 8-8-8-8"; break;
>  	case V4L2_PIX_FMT_RGBA32:	descr = "32-bit RGBA 8-8-8-8"; break;
>  	case V4L2_PIX_FMT_RGBX32:	descr = "32-bit RGBX 8-8-8-8"; break;
> +	case V4L2_PIX_FMT_XBGR2101010:	descr = "32-bit XBGR 2-10-10-10"; break;
> +	case V4L2_PIX_FMT_ABGR2101010:	descr = "32-bit ABGR 2-10-10-10"; break;
> +	case V4L2_PIX_FMT_BGRA1010102:	descr = "32-bit BGRA 10-10-10-2"; break;
>  	case V4L2_PIX_FMT_GREY:		descr = "8-bit Greyscale"; break;
>  	case V4L2_PIX_FMT_Y4:		descr = "4-bit Greyscale"; break;
>  	case V4L2_PIX_FMT_Y6:		descr = "6-bit Greyscale"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 29da1f4b4578..877fd61693b8 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -576,6 +576,9 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGBX32  v4l2_fourcc('X', 'B', '2', '4') /* 32  RGBX-8-8-8-8  */
>  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  ARGB-8-8-8-8  */
>  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  XRGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('R', 'X', '3', '0') /* 32  XBGR-2-10-10-10  */
> +#define V4L2_PIX_FMT_ABGR2101010 v4l2_fourcc('R', 'A', '3', '0') /* 32  ABGR-2-10-10-10  */
> +#define V4L2_PIX_FMT_BGRA1010102 v4l2_fourcc('A', 'R', '3', '0') /* 32  BGRA-10-10-10-2  */
>  
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREY    v4l2_fourcc('G', 'R', 'E', 'Y') /*  8  Greyscale     */

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>  drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>  include/uapi/linux/videodev2.h                |   3 +
>  3 files changed, 200 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> index 30f51cd33f99..de78cd2dcd73 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>      \normalsize
>  
>  
> +10 Bits Per Component
> +=====================
> +
> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> +bytes. They are named based on the order of the RGB components as seen in a
> +32-bit word, which is then stored in memory in little endian byte order
> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
> +number of bits for each component.
> +
> +.. raw:: latex
> +
> +    \begingroup
> +    \tiny
> +    \setlength{\tabcolsep}{2pt}
> +
> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> +
> +
> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> +    :header-rows:  2
> +    :stub-columns: 0
> +
> +    * - Identifier
> +      - Code
> +      - :cspan:`7` Byte 0 in memory
> +      - :cspan:`7` Byte 1
> +      - :cspan:`7` Byte 2
> +      - :cspan:`7` Byte 3
> +    * -
> +      -
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +
> +      - 7
> +      - 6
> +      - 5
> +      - 4
> +      - 3
> +      - 2
> +      - 1
> +      - 0
> +    * .. _V4L2-PIX-FMT-XBGR2101010:
> +
> +      - ``V4L2_PIX_FMT_XBGR2101010``
> +      - 'RX30'
> +
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +      - x
> +      - x
> +
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      -

This doesn't match the text above. This would be RGBX2101010. I'm not
sure which format you want, so I don't know if it's the documentation or
the format name that is incorrect. The next two formats also seem
incorrect to me.

> +    * .. _V4L2-PIX-FMT-ABGR2101010:
> +
> +      - ``V4L2_PIX_FMT_ABGR2101010``
> +      - 'RA30'
> +
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +      - a\ :sub:`1`
> +      - a\ :sub:`0`
> +
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      -
> +    * .. _V4L2-PIX-FMT-BGRA1010102:
> +
> +      - ``V4L2_PIX_FMT_BGRA1010102``
> +      - 'AR30'
> +
> +      - b\ :sub:`7`
> +      - b\ :sub:`6`
> +      - b\ :sub:`5`
> +      - b\ :sub:`4`
> +      - b\ :sub:`3`
> +      - b\ :sub:`2`
> +      - b\ :sub:`1`
> +      - b\ :sub:`0`
> +
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
> +      - b\ :sub:`9`
> +      - b\ :sub:`8`
> +
> +      - r\ :sub:`3`
> +      - r\ :sub:`2`
> +      - r\ :sub:`1`
> +      - r\ :sub:`0`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +
> +      - a\ :sub:`1`
> +      - a\ :sub:`0`
> +      - r\ :sub:`9`
> +      - r\ :sub:`8`
> +      - r\ :sub:`7`
> +      - r\ :sub:`6`
> +      - r\ :sub:`5`
> +      - r\ :sub:`4`
> +      -
> +
> +.. raw:: latex
> +
> +    \endgroup
> +
> +
>  Deprecated RGB Formats
>  ======================
>  
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index fddba75d9074..964300deaf62 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  	case V4L2_PIX_FMT_BGRX32:	descr = "32-bit XBGR 8-8-8-8"; break;
>  	case V4L2_PIX_FMT_RGBA32:	descr = "32-bit RGBA 8-8-8-8"; break;
>  	case V4L2_PIX_FMT_RGBX32:	descr = "32-bit RGBX 8-8-8-8"; break;
> +	case V4L2_PIX_FMT_XBGR2101010:	descr = "32-bit XBGR 2-10-10-10"; break;
> +	case V4L2_PIX_FMT_ABGR2101010:	descr = "32-bit ABGR 2-10-10-10"; break;
> +	case V4L2_PIX_FMT_BGRA1010102:	descr = "32-bit BGRA 10-10-10-2"; break;
>  	case V4L2_PIX_FMT_GREY:		descr = "8-bit Greyscale"; break;
>  	case V4L2_PIX_FMT_Y4:		descr = "4-bit Greyscale"; break;
>  	case V4L2_PIX_FMT_Y6:		descr = "6-bit Greyscale"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 29da1f4b4578..877fd61693b8 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -576,6 +576,9 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGBX32  v4l2_fourcc('X', 'B', '2', '4') /* 32  RGBX-8-8-8-8  */
>  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  ARGB-8-8-8-8  */
>  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  XRGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_XBGR2101010 v4l2_fourcc('R', 'X', '3', '0') /* 32  XBGR-2-10-10-10  */
> +#define V4L2_PIX_FMT_ABGR2101010 v4l2_fourcc('R', 'A', '3', '0') /* 32  ABGR-2-10-10-10  */
> +#define V4L2_PIX_FMT_BGRA1010102 v4l2_fourcc('A', 'R', '3', '0') /* 32  BGRA-10-10-10-2  */
>  
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREY    v4l2_fourcc('G', 'R', 'E', 'Y') /*  8  Greyscale     */

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:34PM +0200, Tomi Valkeinen wrote:
> Add Y210, Y212 and Y216 formats.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../media/v4l/pixfmt-packed-yuv.rst           | 44 +++++++++++++++++++
>  drivers/media/v4l2-core/v4l2-ioctl.c          |  3 ++
>  include/uapi/linux/videodev2.h                |  8 ++++
>  3 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> index bf283a1b5581..3f193e5fd5cb 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> @@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4 bytes.

I would patch the above sentence to mention that it applies to 8 bit
formats.

>        - Y'\ :sub:`3`
>        - Cb\ :sub:`2`
>  
> +The packed YUYV formats with more than 8 bits per component are stored as four
> +16-bit little-endian words. Each word's most significat bits contain one

s/significat/significant/

> +component, and the least significant bits are zero padding.
> +
> +.. tabularcolumns:: |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
> +
> +.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
> +    :header-rows: 1
> +    :stub-columns: 0
> +
> +    * - Identifier
> +      - Code
> +      - Word 0
> +      - Word 1
> +      - Word 2
> +      - Word 3
> +    * .. _V4L2-PIX-FMT-Y210:
> +
> +      - ``V4L2_PIX_FMT_Y210``
> +      - 'Y210'
> +
> +      - Y'\ :sub:`0` (bits 15-6)
> +      - Cb\ :sub:`0` (bits 15-6)
> +      - Y'\ :sub:`1` (bits 15-6)
> +      - Cr\ :sub:`0` (bits 15-6)
> +    * .. _V4L2-PIX-FMT-Y212:
> +
> +      - ``V4L2_PIX_FMT_Y212``
> +      - 'Y212'
> +
> +      - Y'\ :sub:`0` (bits 15-4)
> +      - Cb\ :sub:`0` (bits 15-4)
> +      - Y'\ :sub:`1` (bits 15-4)
> +      - Cr\ :sub:`0` (bits 15-4)
> +    * .. _V4L2-PIX-FMT-Y216:
> +
> +      - ``V4L2_PIX_FMT_Y216``
> +      - 'Y216'
> +
> +      - Y'\ :sub:`0` (bits 15-0)
> +      - Cb\ :sub:`0` (bits 15-0)
> +      - Y'\ :sub:`1` (bits 15-0)
> +      - Cr\ :sub:`0` (bits 15-0)
> +
>  .. raw:: latex
>  
>      \normalsize
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 964300deaf62..ba95389a59b5 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  	case V4L2_META_FMT_RK_ISP1_STAT_3A:	descr = "Rockchip ISP1 3A Statistics"; break;
>  	case V4L2_PIX_FMT_NV12M_8L128:	descr = "NV12M (8x128 Linear)"; break;
>  	case V4L2_PIX_FMT_NV12M_10BE_8L128:	descr = "10-bit NV12M (8x128 Linear, BE)"; break;
> +	case V4L2_PIX_FMT_Y210:		descr = "10-bit YUYV Packed"; break;
> +	case V4L2_PIX_FMT_Y212:		descr = "12-bit YUYV Packed"; break;
> +	case V4L2_PIX_FMT_Y216:		descr = "16-bit YUYV Packed"; break;

While the names will not play nicely with future formats that would swap
the order of the Y, U and V components, they match the formats defined
by DRM, which I think is more important.

With the above small issues fixed,

Conditionally-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

>  
>  	default:
>  		/* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 877fd61693b8..15b640d2da8a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -621,6 +621,14 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_YUVX32  v4l2_fourcc('Y', 'U', 'V', 'X') /* 32  YUVX-8-8-8-8  */
>  #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
>  
> +/*
> + * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy the MSBs
> + * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
> + */
> +#define V4L2_PIX_FMT_Y210    v4l2_fourcc('Y', '2', '1', '0') /* 32  YUYV 4:2:2 */
> +#define V4L2_PIX_FMT_Y212    v4l2_fourcc('Y', '2', '1', '2') /* 32  YUYV 4:2:2 */
> +#define V4L2_PIX_FMT_Y216    v4l2_fourcc('Y', '2', '1', '6') /* 32  YUYV 4:2:2 */
> +
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
>  #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:34PM +0200, Tomi Valkeinen wrote:
> Add Y210, Y212 and Y216 formats.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../media/v4l/pixfmt-packed-yuv.rst           | 44 +++++++++++++++++++
>  drivers/media/v4l2-core/v4l2-ioctl.c          |  3 ++
>  include/uapi/linux/videodev2.h                |  8 ++++
>  3 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> index bf283a1b5581..3f193e5fd5cb 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> @@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4 bytes.

I would patch the above sentence to mention that it applies to 8 bit
formats.

>        - Y'\ :sub:`3`
>        - Cb\ :sub:`2`
>  
> +The packed YUYV formats with more than 8 bits per component are stored as four
> +16-bit little-endian words. Each word's most significat bits contain one

s/significat/significant/

> +component, and the least significant bits are zero padding.
> +
> +.. tabularcolumns:: |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
> +
> +.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
> +    :header-rows: 1
> +    :stub-columns: 0
> +
> +    * - Identifier
> +      - Code
> +      - Word 0
> +      - Word 1
> +      - Word 2
> +      - Word 3
> +    * .. _V4L2-PIX-FMT-Y210:
> +
> +      - ``V4L2_PIX_FMT_Y210``
> +      - 'Y210'
> +
> +      - Y'\ :sub:`0` (bits 15-6)
> +      - Cb\ :sub:`0` (bits 15-6)
> +      - Y'\ :sub:`1` (bits 15-6)
> +      - Cr\ :sub:`0` (bits 15-6)
> +    * .. _V4L2-PIX-FMT-Y212:
> +
> +      - ``V4L2_PIX_FMT_Y212``
> +      - 'Y212'
> +
> +      - Y'\ :sub:`0` (bits 15-4)
> +      - Cb\ :sub:`0` (bits 15-4)
> +      - Y'\ :sub:`1` (bits 15-4)
> +      - Cr\ :sub:`0` (bits 15-4)
> +    * .. _V4L2-PIX-FMT-Y216:
> +
> +      - ``V4L2_PIX_FMT_Y216``
> +      - 'Y216'
> +
> +      - Y'\ :sub:`0` (bits 15-0)
> +      - Cb\ :sub:`0` (bits 15-0)
> +      - Y'\ :sub:`1` (bits 15-0)
> +      - Cr\ :sub:`0` (bits 15-0)
> +
>  .. raw:: latex
>  
>      \normalsize
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 964300deaf62..ba95389a59b5 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  	case V4L2_META_FMT_RK_ISP1_STAT_3A:	descr = "Rockchip ISP1 3A Statistics"; break;
>  	case V4L2_PIX_FMT_NV12M_8L128:	descr = "NV12M (8x128 Linear)"; break;
>  	case V4L2_PIX_FMT_NV12M_10BE_8L128:	descr = "10-bit NV12M (8x128 Linear, BE)"; break;
> +	case V4L2_PIX_FMT_Y210:		descr = "10-bit YUYV Packed"; break;
> +	case V4L2_PIX_FMT_Y212:		descr = "12-bit YUYV Packed"; break;
> +	case V4L2_PIX_FMT_Y216:		descr = "16-bit YUYV Packed"; break;

While the names will not play nicely with future formats that would swap
the order of the Y, U and V components, they match the formats defined
by DRM, which I think is more important.

With the above small issues fixed,

Conditionally-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

>  
>  	default:
>  		/* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 877fd61693b8..15b640d2da8a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -621,6 +621,14 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_YUVX32  v4l2_fourcc('Y', 'U', 'V', 'X') /* 32  YUVX-8-8-8-8  */
>  #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
>  
> +/*
> + * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy the MSBs
> + * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
> + */
> +#define V4L2_PIX_FMT_Y210    v4l2_fourcc('Y', '2', '1', '0') /* 32  YUYV 4:2:2 */
> +#define V4L2_PIX_FMT_Y212    v4l2_fourcc('Y', '2', '1', '2') /* 32  YUYV 4:2:2 */
> +#define V4L2_PIX_FMT_Y216    v4l2_fourcc('Y', '2', '1', '6') /* 32  YUYV 4:2:2 */
> +
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
>  #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen4, not gen3. The same IP is also used in the
> (not-yet-supported) V4H.
> 
> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> to represent the model correctly. V3U and V4H can still be
> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
> 
> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> and update the code to correcly match for gen 4.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
>  drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
>  drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
>  7 files changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> index c260d318d298..5710152d6511 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
>  		.wpf_count = 2,
>  		.num_bru_inputs = 5,
>  	}, {
> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
>  		.model = "VSP2-D",
> -		.gen = 3,
> +		.gen = 4,
>  		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
>  		.lif_count = 1,
>  		.rpf_count = 5,
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> index bf3f981f93a1..e6492deb0a64 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
>  
>  	/* Initialize the control handler. */
>  	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
> -			       vsp1->info->gen == 3 ? 2 : 1);
> +			       vsp1->info->gen >= 3 ? 2 : 1);
>  	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>  						  &hgo_max_rgb_control, NULL);
> -	if (vsp1->info->gen == 3)
> +	if (vsp1->info->gen >= 3)
>  		hgo->ctrls.num_bins =
>  			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>  					     &hgo_num_bins_control, NULL);
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> index 186a5730e1e3..0ab2e0c70474 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
>  		break;
>  
>  	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:

While this doesn't cause any functional change, it doesn't fall into the
renaming explained in the commit message. I'd make a mention of it
there.

Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

>  	default:
>  		hbth = 0;
>  		obth = 3000;
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8928f4c6bb55..8c9333f76858 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -766,7 +766,7 @@
>  #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
>  /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
>  #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 75083cb234fe..045aa54f7998 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>  	 * otherwise.
>  	 *
> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
>  	 * alpha channel by a fixed global alpha value, and multiply the pixel
>  	 * components to convert the input to premultiplied alpha.
>  	 *
>  	 * As alpha premultiplication is available in the BRx for both Gen2 and
> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
>  	 * alpha multiplication only. This however prevents conversion to
>  	 * premultiplied alpha if no BRx is present in the pipeline. If that use
>  	 * case turns out to be useful we will revisit the implementation (for
>  	 * Gen3 only).
>  	 *
> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
>  	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
>  	 * contains an alpha channel. On Gen2 the global alpha is ignored in
>  	 * that case.
> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
>  				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
>  
> -	if (entity->vsp1->info->gen == 3) {
> +	if (entity->vsp1->info->gen >= 3) {
>  		u32 mult;
>  
>  		if (fmtinfo->alpha) {
> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
>  	}
>  
>  	/*
> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>  	 * formats. Swap the U and V planes manually in that case.
>  	 */
> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>  	    fmtinfo->swap_uv)
>  		swap(mem.addr[1], mem.addr[2]);
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> index 9d24647c8f32..544012fd1fe9 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
>  	div_size = format->width;
>  
>  	/*
> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
>  	 * with a single partition that covers the whole output.
>  	 */
> -	if (vsp1->info->gen == 3) {
> +	if (vsp1->info->gen >= 3) {
>  		list_for_each_entry(entity, &pipe->entities, list_pipe) {
>  			unsigned int entity_max;
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> index 94e91d7bb56c..d0074ca00920 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
>  	}
>  
>  	/*
> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>  	 * formats. Swap the U and V planes manually in that case.
>  	 */
> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>  	    fmtinfo->swap_uv)
>  		swap(mem.addr[1], mem.addr[2]);
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen4, not gen3. The same IP is also used in the
> (not-yet-supported) V4H.
> 
> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> to represent the model correctly. V3U and V4H can still be
> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
> 
> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> and update the code to correcly match for gen 4.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
>  drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
>  drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
>  7 files changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> index c260d318d298..5710152d6511 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
>  		.wpf_count = 2,
>  		.num_bru_inputs = 5,
>  	}, {
> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
>  		.model = "VSP2-D",
> -		.gen = 3,
> +		.gen = 4,
>  		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
>  		.lif_count = 1,
>  		.rpf_count = 5,
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> index bf3f981f93a1..e6492deb0a64 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
>  
>  	/* Initialize the control handler. */
>  	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
> -			       vsp1->info->gen == 3 ? 2 : 1);
> +			       vsp1->info->gen >= 3 ? 2 : 1);
>  	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>  						  &hgo_max_rgb_control, NULL);
> -	if (vsp1->info->gen == 3)
> +	if (vsp1->info->gen >= 3)
>  		hgo->ctrls.num_bins =
>  			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>  					     &hgo_num_bins_control, NULL);
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> index 186a5730e1e3..0ab2e0c70474 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
>  		break;
>  
>  	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:

While this doesn't cause any functional change, it doesn't fall into the
renaming explained in the commit message. I'd make a mention of it
there.

Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

>  	default:
>  		hbth = 0;
>  		obth = 3000;
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8928f4c6bb55..8c9333f76858 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -766,7 +766,7 @@
>  #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
>  /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
>  #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 75083cb234fe..045aa54f7998 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>  	 * otherwise.
>  	 *
> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
>  	 * alpha channel by a fixed global alpha value, and multiply the pixel
>  	 * components to convert the input to premultiplied alpha.
>  	 *
>  	 * As alpha premultiplication is available in the BRx for both Gen2 and
> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
>  	 * alpha multiplication only. This however prevents conversion to
>  	 * premultiplied alpha if no BRx is present in the pipeline. If that use
>  	 * case turns out to be useful we will revisit the implementation (for
>  	 * Gen3 only).
>  	 *
> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
>  	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
>  	 * contains an alpha channel. On Gen2 the global alpha is ignored in
>  	 * that case.
> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
>  				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
>  
> -	if (entity->vsp1->info->gen == 3) {
> +	if (entity->vsp1->info->gen >= 3) {
>  		u32 mult;
>  
>  		if (fmtinfo->alpha) {
> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
>  	}
>  
>  	/*
> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>  	 * formats. Swap the U and V planes manually in that case.
>  	 */
> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>  	    fmtinfo->swap_uv)
>  		swap(mem.addr[1], mem.addr[2]);
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> index 9d24647c8f32..544012fd1fe9 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
>  	div_size = format->width;
>  
>  	/*
> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
>  	 * with a single partition that covers the whole output.
>  	 */
> -	if (vsp1->info->gen == 3) {
> +	if (vsp1->info->gen >= 3) {
>  		list_for_each_entry(entity, &pipe->entities, list_pipe) {
>  			unsigned int entity_max;
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> index 94e91d7bb56c..d0074ca00920 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
>  	}
>  
>  	/*
> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>  	 * formats. Swap the U and V planes manually in that case.
>  	 */
> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>  	    fmtinfo->swap_uv)
>  		swap(mem.addr[1], mem.addr[2]);
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:36PM +0200, Tomi Valkeinen wrote:
> Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> ---
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8c9333f76858..c61e8dafeecf 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -782,6 +782,7 @@
>  #define VI6_IP_VERSION_SOC_M3N		(0x04 << 0)
>  #define VI6_IP_VERSION_SOC_E3		(0x04 << 0)
>  #define VI6_IP_VERSION_SOC_V3U		(0x05 << 0)
> +#define VI6_IP_VERSION_SOC_V4H		(0x06 << 0)
>  /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification */
>  #define VI6_IP_VERSION_SOC_RZG2L	(0x80 << 0)
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:36PM +0200, Tomi Valkeinen wrote:
> Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> ---
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8c9333f76858..c61e8dafeecf 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -782,6 +782,7 @@
>  #define VI6_IP_VERSION_SOC_M3N		(0x04 << 0)
>  #define VI6_IP_VERSION_SOC_E3		(0x04 << 0)
>  #define VI6_IP_VERSION_SOC_V3U		(0x05 << 0)
> +#define VI6_IP_VERSION_SOC_V4H		(0x06 << 0)
>  /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification */
>  #define VI6_IP_VERSION_SOC_RZG2L	(0x80 << 0)
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:37PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../media/platform/renesas/vsp1/vsp1_pipe.c   | 15 ++++++
>  .../media/platform/renesas/vsp1/vsp1_regs.h   | 22 +++++++++
>  .../media/platform/renesas/vsp1/vsp1_rpf.c    | 49 +++++++++++++++++++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> index f72ac01c21ea..2867b3de06fa 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> @@ -146,6 +146,18 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
>  	  VI6_FMT_ARGB_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
>  	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
>  	{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
>  	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> @@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
>  	  VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
>  	  3, { 8, 8, 8 }, false, true, 1, 1, false },
> +	{ V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
> +	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 2, 1, false },
>  };
>  
>  /**
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index c61e8dafeecf..8947ea05f95e 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -228,6 +228,27 @@
>  #define VI6_RPF_MULT_ALPHA_RATIO_MASK	(0xff << 0)
>  #define VI6_RPF_MULT_ALPHA_RATIO_SHIFT	0
>  
> +#define VI6_RPF_EXT_INFMT0		0x0370
> +#define VI6_RPF_EXT_INFMT0_F2B_LSB		(0 << 12)
> +#define VI6_RPF_EXT_INFMT0_F2B_MSB		(1 << 12)

We don't normally define two macros for each bit. You can drop the
F2B_LSB macro, rename F2B_MSB to F2B, and use BIT(12).

> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_8		(0 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_10		(1 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_12		(2 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_8		(0 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_10		(1 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_12		(2 << 4)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10	(3 << 0)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10	(0 << 0)

I would drop the last one as you don't use it.

> +
> +#define VI6_RPF_EXT_INFMT1		0x0374
> +#define VI6_RPF_EXT_INFMT2		0x0378
> +
> +#define VI6_RPF_BRDITH_CTRL		0x03e0
> +#define VI6_RPF_BRDITH_CTRL_ODE_EN	(1 << 8)
> +#define VI6_RPF_BRDITH_CTRL_ODE_DIS	(0 << 8)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_RO	(1 << 0)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_TR	(0 << 0)

Same here, one macro per bit.

The BRDITH_CTRL registers doesn't seem to be used. I don't mind adding
it though.

> +
>  /* -----------------------------------------------------------------------------
>   * WPF Control Registers
>   */
> @@ -846,6 +867,7 @@
>  #define VI6_FMT_XBXGXR_262626		0x21
>  #define VI6_FMT_ABGR_8888		0x22
>  #define VI6_FMT_XXRGB_88565		0x23
> +#define VI6_FMT_RGB10_RGB10A2_A2RGB10	0x30
>  
>  #define VI6_FMT_Y_UV_444		0x40
>  #define VI6_FMT_Y_UV_422		0x41
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 045aa54f7998..60ba3c62e86c 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
>   * VSP1 Entity Operations
>   */
>  
> +#define PACK_CPOS(a, b, c, d) \
> +	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +#define PACK_CLEN(a, b, c, d) \
> +	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +

Please move this to vsp1_regs.h, just below the corresponding registers.
I would also prefer giving the macros names that related to the
registers.

>  static void rpf_configure_stream(struct vsp1_entity *entity,
>  				 struct vsp1_pipeline *pipe,
>  				 struct vsp1_dl_list *dl,
> @@ -109,6 +114,50 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  	vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
>  	vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
>  
> +	if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) == VI6_IP_VERSION_MODEL_VSPD_GEN4) {

Please wrap this as

	if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
	    VI6_IP_VERSION_MODEL_VSPD_GEN4) {

You could also test entity->vsp1->gen == 4, up to you.

> +		u32 ext_infmt0;
> +		u32 ext_infmt1;
> +		u32 ext_infmt2;
> +
> +		switch (fmtinfo->fourcc) {
> +		case V4L2_PIX_FMT_XBGR2101010:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(0, 10, 20, 0);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 0);

While this matches the detailed bit order of the V4L2 format as defined
in patch 1/7, it doesn't match the XBGR2101010 name, at least if
interpreted the same way as DRM_FORMAT_XBGR2101010. I think this should
be DRM_FORMAT_RGBX1010102 instead.

Same for the nex two formats, they should be RGBA1010102 and
ARGB2101010.

> +			break;
> +
> +		case V4L2_PIX_FMT_ABGR2101010:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(0, 10, 20, 30);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
> +			break;
> +
> +		case V4L2_PIX_FMT_BGRA1010102:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(2, 12, 22, 0);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
> +			break;
> +
> +		case V4L2_PIX_FMT_Y210:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_F2B_MSB |
> +				     VI6_RPF_EXT_INFMT0_IPBD_Y_10 |
> +				     VI6_RPF_EXT_INFMT0_IPBD_C_10;
> +			ext_infmt1 = 0x0;
> +			ext_infmt2 = 0x0;
> +			break;
> +
> +		default:
> +			ext_infmt0 = 0;
> +			ext_infmt1 = 0;
> +			ext_infmt2 = 0;
> +			break;
> +		}
> +
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT0, ext_infmt0);
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT1, ext_infmt1);
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT2, ext_infmt2);
> +	}
> +
>  	/* Output location. */
>  	if (pipe->brx) {
>  		const struct v4l2_rect *compose;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:37PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  .../media/platform/renesas/vsp1/vsp1_pipe.c   | 15 ++++++
>  .../media/platform/renesas/vsp1/vsp1_regs.h   | 22 +++++++++
>  .../media/platform/renesas/vsp1/vsp1_rpf.c    | 49 +++++++++++++++++++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> index f72ac01c21ea..2867b3de06fa 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> @@ -146,6 +146,18 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
>  	  VI6_FMT_ARGB_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
>  	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> +	{ V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB8888_1X32,
> +	  VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +	  VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
>  	{ V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
>  	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> @@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
>  	  VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
>  	  3, { 8, 8, 8 }, false, true, 1, 1, false },
> +	{ V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
> +	  VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +	  1, { 32, 0, 0 }, false, false, 2, 1, false },
>  };
>  
>  /**
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index c61e8dafeecf..8947ea05f95e 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -228,6 +228,27 @@
>  #define VI6_RPF_MULT_ALPHA_RATIO_MASK	(0xff << 0)
>  #define VI6_RPF_MULT_ALPHA_RATIO_SHIFT	0
>  
> +#define VI6_RPF_EXT_INFMT0		0x0370
> +#define VI6_RPF_EXT_INFMT0_F2B_LSB		(0 << 12)
> +#define VI6_RPF_EXT_INFMT0_F2B_MSB		(1 << 12)

We don't normally define two macros for each bit. You can drop the
F2B_LSB macro, rename F2B_MSB to F2B, and use BIT(12).

> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_8		(0 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_10		(1 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_12		(2 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_8		(0 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_10		(1 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_12		(2 << 4)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10	(3 << 0)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10	(0 << 0)

I would drop the last one as you don't use it.

> +
> +#define VI6_RPF_EXT_INFMT1		0x0374
> +#define VI6_RPF_EXT_INFMT2		0x0378
> +
> +#define VI6_RPF_BRDITH_CTRL		0x03e0
> +#define VI6_RPF_BRDITH_CTRL_ODE_EN	(1 << 8)
> +#define VI6_RPF_BRDITH_CTRL_ODE_DIS	(0 << 8)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_RO	(1 << 0)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_TR	(0 << 0)

Same here, one macro per bit.

The BRDITH_CTRL registers doesn't seem to be used. I don't mind adding
it though.

> +
>  /* -----------------------------------------------------------------------------
>   * WPF Control Registers
>   */
> @@ -846,6 +867,7 @@
>  #define VI6_FMT_XBXGXR_262626		0x21
>  #define VI6_FMT_ABGR_8888		0x22
>  #define VI6_FMT_XXRGB_88565		0x23
> +#define VI6_FMT_RGB10_RGB10A2_A2RGB10	0x30
>  
>  #define VI6_FMT_Y_UV_444		0x40
>  #define VI6_FMT_Y_UV_422		0x41
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 045aa54f7998..60ba3c62e86c 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
>   * VSP1 Entity Operations
>   */
>  
> +#define PACK_CPOS(a, b, c, d) \
> +	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +#define PACK_CLEN(a, b, c, d) \
> +	(((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +

Please move this to vsp1_regs.h, just below the corresponding registers.
I would also prefer giving the macros names that related to the
registers.

>  static void rpf_configure_stream(struct vsp1_entity *entity,
>  				 struct vsp1_pipeline *pipe,
>  				 struct vsp1_dl_list *dl,
> @@ -109,6 +114,50 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>  	vsp1_rpf_write(rpf, dlb, VI6_RPF_INFMT, infmt);
>  	vsp1_rpf_write(rpf, dlb, VI6_RPF_DSWAP, fmtinfo->swap);
>  
> +	if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) == VI6_IP_VERSION_MODEL_VSPD_GEN4) {

Please wrap this as

	if ((entity->vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
	    VI6_IP_VERSION_MODEL_VSPD_GEN4) {

You could also test entity->vsp1->gen == 4, up to you.

> +		u32 ext_infmt0;
> +		u32 ext_infmt1;
> +		u32 ext_infmt2;
> +
> +		switch (fmtinfo->fourcc) {
> +		case V4L2_PIX_FMT_XBGR2101010:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(0, 10, 20, 0);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 0);

While this matches the detailed bit order of the V4L2 format as defined
in patch 1/7, it doesn't match the XBGR2101010 name, at least if
interpreted the same way as DRM_FORMAT_XBGR2101010. I think this should
be DRM_FORMAT_RGBX1010102 instead.

Same for the nex two formats, they should be RGBA1010102 and
ARGB2101010.

> +			break;
> +
> +		case V4L2_PIX_FMT_ABGR2101010:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(0, 10, 20, 30);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
> +			break;
> +
> +		case V4L2_PIX_FMT_BGRA1010102:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10;
> +			ext_infmt1 = PACK_CPOS(2, 12, 22, 0);
> +			ext_infmt2 = PACK_CLEN(10, 10, 10, 2);
> +			break;
> +
> +		case V4L2_PIX_FMT_Y210:
> +			ext_infmt0 = VI6_RPF_EXT_INFMT0_F2B_MSB |
> +				     VI6_RPF_EXT_INFMT0_IPBD_Y_10 |
> +				     VI6_RPF_EXT_INFMT0_IPBD_C_10;
> +			ext_infmt1 = 0x0;
> +			ext_infmt2 = 0x0;
> +			break;
> +
> +		default:
> +			ext_infmt0 = 0;
> +			ext_infmt1 = 0;
> +			ext_infmt2 = 0;
> +			break;
> +		}
> +
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT0, ext_infmt0);
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT1, ext_infmt1);
> +		vsp1_rpf_write(rpf, dlb, VI6_RPF_EXT_INFMT2, ext_infmt2);
> +	}
> +
>  	/* Output location. */
>  	if (pipe->brx) {
>  		const struct v4l2_rect *compose;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:38PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
> rcar_du_r8a779a0_info.

With the typo reporting by Kieran fixed,

Conditionally-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info rcar_du_r8a7799x_info = {
>  };
>  
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> -	.gen = 3,
> +	.gen = 4,
>  	.features = RCAR_DU_FEATURE_CRTC_IRQ
>  		  | RCAR_DU_FEATURE_VSP1_SOURCE
>  		  | RCAR_DU_FEATURE_NO_BLENDING,

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:38PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
> rcar_du_r8a779a0_info.

With the typo reporting by Kieran fixed,

Conditionally-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info rcar_du_r8a7799x_info = {
>  };
>  
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> -	.gen = 3,
> +	.gen = 4,
>  	.features = RCAR_DU_FEATURE_CRTC_IRQ
>  		  | RCAR_DU_FEATURE_VSP1_SOURCE
>  		  | RCAR_DU_FEATURE_NO_BLENDING,

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Tomi,

(CC'ing Sakari and Hans)

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>  2 files changed, 71 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 8c2719efda2a..8ccabf5a30c4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>  		.bpp = 32,
>  		.planes = 1,
>  		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGBX1010102,

Ah, here the format makes sense.

> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,

But this is horrible :-( Could we use the same names as DRM for new
formats, when there is no conflict with existing V4L2 formats ?

Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
the format definitions.

> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGBA1010102,
> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_ARGB2101010,
> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
>  	}, {
>  		.fourcc = DRM_FORMAT_YVYU,
>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>  		.bpp = 24,
>  		.planes = 3,
>  		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_Y210,
> +		.v4l2 = V4L2_PIX_FMT_Y210,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 2,
>  	},

Any reason why you'd not adding Y212 support already ?

>  };
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index e465aef41585..6f3e109a4f80 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>  	DRM_FORMAT_YVU444,
>  };
>  
> +/*
> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> + * formats and Y210 format.
> + */
> +static const u32 rcar_du_vsp_formats_gen4[] = {
> +	DRM_FORMAT_RGB332,
> +	DRM_FORMAT_ARGB4444,
> +	DRM_FORMAT_XRGB4444,
> +	DRM_FORMAT_ARGB1555,
> +	DRM_FORMAT_XRGB1555,
> +	DRM_FORMAT_RGB565,
> +	DRM_FORMAT_BGR888,
> +	DRM_FORMAT_RGB888,
> +	DRM_FORMAT_BGRA8888,
> +	DRM_FORMAT_BGRX8888,
> +	DRM_FORMAT_ARGB8888,
> +	DRM_FORMAT_XRGB8888,
> +	DRM_FORMAT_RGBX1010102,
> +	DRM_FORMAT_RGBA1010102,
> +	DRM_FORMAT_ARGB2101010,
> +	DRM_FORMAT_UYVY,
> +	DRM_FORMAT_YUYV,
> +	DRM_FORMAT_YVYU,
> +	DRM_FORMAT_NV12,
> +	DRM_FORMAT_NV21,
> +	DRM_FORMAT_NV16,
> +	DRM_FORMAT_NV61,
> +	DRM_FORMAT_YUV420,
> +	DRM_FORMAT_YVU420,
> +	DRM_FORMAT_YUV422,
> +	DRM_FORMAT_YVU422,
> +	DRM_FORMAT_YUV444,
> +	DRM_FORMAT_YVU444,
> +	DRM_FORMAT_Y210,
> +};
> +
>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>  {
>  	struct rcar_du_vsp_plane_state *state =
> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>  					 ? DRM_PLANE_TYPE_PRIMARY
>  					 : DRM_PLANE_TYPE_OVERLAY;
>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> +		unsigned int num_formats;
> +		const u32 *formats;
> +
> +		if (rcdu->info->gen < 4) {
> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> +			formats = rcar_du_vsp_formats;
> +		} else {
> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> +			formats = rcar_du_vsp_formats_gen4;
> +		}
>  
>  		plane->vsp = vsp;
>  		plane->index = i;
>  
>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>  					       crtcs, &rcar_du_vsp_plane_funcs,
> -					       rcar_du_vsp_formats,
> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> +					       formats, num_formats,
>  					       NULL, type, NULL);
>  		if (ret < 0)
>  			return ret;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Tomi,

(CC'ing Sakari and Hans)

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>  2 files changed, 71 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 8c2719efda2a..8ccabf5a30c4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>  		.bpp = 32,
>  		.planes = 1,
>  		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGBX1010102,

Ah, here the format makes sense.

> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,

But this is horrible :-( Could we use the same names as DRM for new
formats, when there is no conflict with existing V4L2 formats ?

Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
the format definitions.

> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_RGBA1010102,
> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_ARGB2101010,
> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 1,
>  	}, {
>  		.fourcc = DRM_FORMAT_YVYU,
>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>  		.bpp = 24,
>  		.planes = 3,
>  		.hsub = 1,
> +	}, {
> +		.fourcc = DRM_FORMAT_Y210,
> +		.v4l2 = V4L2_PIX_FMT_Y210,
> +		.bpp = 32,
> +		.planes = 1,
> +		.hsub = 2,
>  	},

Any reason why you'd not adding Y212 support already ?

>  };
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index e465aef41585..6f3e109a4f80 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>  	DRM_FORMAT_YVU444,
>  };
>  
> +/*
> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> + * formats and Y210 format.
> + */
> +static const u32 rcar_du_vsp_formats_gen4[] = {
> +	DRM_FORMAT_RGB332,
> +	DRM_FORMAT_ARGB4444,
> +	DRM_FORMAT_XRGB4444,
> +	DRM_FORMAT_ARGB1555,
> +	DRM_FORMAT_XRGB1555,
> +	DRM_FORMAT_RGB565,
> +	DRM_FORMAT_BGR888,
> +	DRM_FORMAT_RGB888,
> +	DRM_FORMAT_BGRA8888,
> +	DRM_FORMAT_BGRX8888,
> +	DRM_FORMAT_ARGB8888,
> +	DRM_FORMAT_XRGB8888,
> +	DRM_FORMAT_RGBX1010102,
> +	DRM_FORMAT_RGBA1010102,
> +	DRM_FORMAT_ARGB2101010,
> +	DRM_FORMAT_UYVY,
> +	DRM_FORMAT_YUYV,
> +	DRM_FORMAT_YVYU,
> +	DRM_FORMAT_NV12,
> +	DRM_FORMAT_NV21,
> +	DRM_FORMAT_NV16,
> +	DRM_FORMAT_NV61,
> +	DRM_FORMAT_YUV420,
> +	DRM_FORMAT_YVU420,
> +	DRM_FORMAT_YUV422,
> +	DRM_FORMAT_YVU422,
> +	DRM_FORMAT_YUV444,
> +	DRM_FORMAT_YVU444,
> +	DRM_FORMAT_Y210,
> +};
> +
>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>  {
>  	struct rcar_du_vsp_plane_state *state =
> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>  					 ? DRM_PLANE_TYPE_PRIMARY
>  					 : DRM_PLANE_TYPE_OVERLAY;
>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> +		unsigned int num_formats;
> +		const u32 *formats;
> +
> +		if (rcdu->info->gen < 4) {
> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> +			formats = rcar_du_vsp_formats;
> +		} else {
> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> +			formats = rcar_du_vsp_formats_gen4;
> +		}
>  
>  		plane->vsp = vsp;
>  		plane->index = i;
>  
>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>  					       crtcs, &rcar_du_vsp_plane_funcs,
> -					       rcar_du_vsp_formats,
> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> +					       formats, num_formats,
>  					       NULL, type, NULL);
>  		if (ret < 0)
>  			return ret;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 19/12/2022 22:47, Laurent Pinchart wrote:
> Hi Tomi,
> 
> (CC'ing Sakari and Hans)
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> index 8c2719efda2a..8ccabf5a30c4 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>  		.bpp = 32,
>>  		.planes = 1,
>>  		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_RGBX1010102,
> 
> Ah, here the format makes sense.
> 
>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> 
> But this is horrible :-( Could we use the same names as DRM for new
> formats, when there is no conflict with existing V4L2 formats ?
> 
> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> the format definitions.

V4L2 describes pixel formats based on how they appear in memory from the
lowest to highest memory address.

If I am not mistaken, DRM uses the CPU order. So that explains the difference
in naming. I don't think we should hide that difference. And V4L2 has been
quite consistent in following memory ordering in the naming (except possibly
for some of the really old pixelformats).

Departing from that would be more of a hindrance than a help, IMHO.

Regards,

	Hans

> 
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_RGBA1010102,
>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_ARGB2101010,
>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>>  	}, {
>>  		.fourcc = DRM_FORMAT_YVYU,
>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>  		.bpp = 24,
>>  		.planes = 3,
>>  		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_Y210,
>> +		.v4l2 = V4L2_PIX_FMT_Y210,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 2,
>>  	},
> 
> Any reason why you'd not adding Y212 support already ?
> 
>>  };
>>  
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> index e465aef41585..6f3e109a4f80 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>>  	DRM_FORMAT_YVU444,
>>  };
>>  
>> +/*
>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
>> + * formats and Y210 format.
>> + */
>> +static const u32 rcar_du_vsp_formats_gen4[] = {
>> +	DRM_FORMAT_RGB332,
>> +	DRM_FORMAT_ARGB4444,
>> +	DRM_FORMAT_XRGB4444,
>> +	DRM_FORMAT_ARGB1555,
>> +	DRM_FORMAT_XRGB1555,
>> +	DRM_FORMAT_RGB565,
>> +	DRM_FORMAT_BGR888,
>> +	DRM_FORMAT_RGB888,
>> +	DRM_FORMAT_BGRA8888,
>> +	DRM_FORMAT_BGRX8888,
>> +	DRM_FORMAT_ARGB8888,
>> +	DRM_FORMAT_XRGB8888,
>> +	DRM_FORMAT_RGBX1010102,
>> +	DRM_FORMAT_RGBA1010102,
>> +	DRM_FORMAT_ARGB2101010,
>> +	DRM_FORMAT_UYVY,
>> +	DRM_FORMAT_YUYV,
>> +	DRM_FORMAT_YVYU,
>> +	DRM_FORMAT_NV12,
>> +	DRM_FORMAT_NV21,
>> +	DRM_FORMAT_NV16,
>> +	DRM_FORMAT_NV61,
>> +	DRM_FORMAT_YUV420,
>> +	DRM_FORMAT_YVU420,
>> +	DRM_FORMAT_YUV422,
>> +	DRM_FORMAT_YVU422,
>> +	DRM_FORMAT_YUV444,
>> +	DRM_FORMAT_YVU444,
>> +	DRM_FORMAT_Y210,
>> +};
>> +
>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>>  {
>>  	struct rcar_du_vsp_plane_state *state =
>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>>  					 ? DRM_PLANE_TYPE_PRIMARY
>>  					 : DRM_PLANE_TYPE_OVERLAY;
>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
>> +		unsigned int num_formats;
>> +		const u32 *formats;
>> +
>> +		if (rcdu->info->gen < 4) {
>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
>> +			formats = rcar_du_vsp_formats;
>> +		} else {
>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
>> +			formats = rcar_du_vsp_formats_gen4;
>> +		}
>>  
>>  		plane->vsp = vsp;
>>  		plane->index = i;
>>  
>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>>  					       crtcs, &rcar_du_vsp_plane_funcs,
>> -					       rcar_du_vsp_formats,
>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
>> +					       formats, num_formats,
>>  					       NULL, type, NULL);
>>  		if (ret < 0)
>>  			return ret;
> 

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 19/12/2022 22:47, Laurent Pinchart wrote:
> Hi Tomi,
> 
> (CC'ing Sakari and Hans)
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> index 8c2719efda2a..8ccabf5a30c4 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>  		.bpp = 32,
>>  		.planes = 1,
>>  		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_RGBX1010102,
> 
> Ah, here the format makes sense.
> 
>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> 
> But this is horrible :-( Could we use the same names as DRM for new
> formats, when there is no conflict with existing V4L2 formats ?
> 
> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> the format definitions.

V4L2 describes pixel formats based on how they appear in memory from the
lowest to highest memory address.

If I am not mistaken, DRM uses the CPU order. So that explains the difference
in naming. I don't think we should hide that difference. And V4L2 has been
quite consistent in following memory ordering in the naming (except possibly
for some of the really old pixelformats).

Departing from that would be more of a hindrance than a help, IMHO.

Regards,

	Hans

> 
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_RGBA1010102,
>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_ARGB2101010,
>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 1,
>>  	}, {
>>  		.fourcc = DRM_FORMAT_YVYU,
>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>  		.bpp = 24,
>>  		.planes = 3,
>>  		.hsub = 1,
>> +	}, {
>> +		.fourcc = DRM_FORMAT_Y210,
>> +		.v4l2 = V4L2_PIX_FMT_Y210,
>> +		.bpp = 32,
>> +		.planes = 1,
>> +		.hsub = 2,
>>  	},
> 
> Any reason why you'd not adding Y212 support already ?
> 
>>  };
>>  
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> index e465aef41585..6f3e109a4f80 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>>  	DRM_FORMAT_YVU444,
>>  };
>>  
>> +/*
>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
>> + * formats and Y210 format.
>> + */
>> +static const u32 rcar_du_vsp_formats_gen4[] = {
>> +	DRM_FORMAT_RGB332,
>> +	DRM_FORMAT_ARGB4444,
>> +	DRM_FORMAT_XRGB4444,
>> +	DRM_FORMAT_ARGB1555,
>> +	DRM_FORMAT_XRGB1555,
>> +	DRM_FORMAT_RGB565,
>> +	DRM_FORMAT_BGR888,
>> +	DRM_FORMAT_RGB888,
>> +	DRM_FORMAT_BGRA8888,
>> +	DRM_FORMAT_BGRX8888,
>> +	DRM_FORMAT_ARGB8888,
>> +	DRM_FORMAT_XRGB8888,
>> +	DRM_FORMAT_RGBX1010102,
>> +	DRM_FORMAT_RGBA1010102,
>> +	DRM_FORMAT_ARGB2101010,
>> +	DRM_FORMAT_UYVY,
>> +	DRM_FORMAT_YUYV,
>> +	DRM_FORMAT_YVYU,
>> +	DRM_FORMAT_NV12,
>> +	DRM_FORMAT_NV21,
>> +	DRM_FORMAT_NV16,
>> +	DRM_FORMAT_NV61,
>> +	DRM_FORMAT_YUV420,
>> +	DRM_FORMAT_YVU420,
>> +	DRM_FORMAT_YUV422,
>> +	DRM_FORMAT_YVU422,
>> +	DRM_FORMAT_YUV444,
>> +	DRM_FORMAT_YVU444,
>> +	DRM_FORMAT_Y210,
>> +};
>> +
>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>>  {
>>  	struct rcar_du_vsp_plane_state *state =
>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>>  					 ? DRM_PLANE_TYPE_PRIMARY
>>  					 : DRM_PLANE_TYPE_OVERLAY;
>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
>> +		unsigned int num_formats;
>> +		const u32 *formats;
>> +
>> +		if (rcdu->info->gen < 4) {
>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
>> +			formats = rcar_du_vsp_formats;
>> +		} else {
>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
>> +			formats = rcar_du_vsp_formats_gen4;
>> +		}
>>  
>>  		plane->vsp = vsp;
>>  		plane->index = i;
>>  
>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>>  					       crtcs, &rcar_du_vsp_plane_funcs,
>> -					       rcar_du_vsp_formats,
>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
>> +					       formats, num_formats,
>>  					       NULL, type, NULL);
>>  		if (ret < 0)
>>  			return ret;
> 

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Geert Uytterhoeven]

Hi Hans,

On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > (CC'ing Sakari and Hans)
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> index 8c2719efda2a..8ccabf5a30c4 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>              .bpp = 32,
> >>              .planes = 1,
> >>              .hsub = 1,
> >> +    }, {
> >> +            .fourcc = DRM_FORMAT_RGBX1010102,
> >
> > Ah, here the format makes sense.
> >
> >> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> >
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
>
> V4L2 describes pixel formats based on how they appear in memory from the
> lowest to highest memory address.

So that means big endian?

> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> in naming. I don't think we should hide that difference. And V4L2 has been
> quite consistent in following memory ordering in the naming (except possibly
> for some of the really old pixelformats).

DRM uses little endian.

> Departing from that would be more of a hindrance than a help, IMHO.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Geert Uytterhoeven]

Hi Hans,

On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > (CC'ing Sakari and Hans)
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> index 8c2719efda2a..8ccabf5a30c4 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>              .bpp = 32,
> >>              .planes = 1,
> >>              .hsub = 1,
> >> +    }, {
> >> +            .fourcc = DRM_FORMAT_RGBX1010102,
> >
> > Ah, here the format makes sense.
> >
> >> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> >
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
>
> V4L2 describes pixel formats based on how they appear in memory from the
> lowest to highest memory address.

So that means big endian?

> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> in naming. I don't think we should hide that difference. And V4L2 has been
> quite consistent in following memory ordering in the naming (except possibly
> for some of the really old pixelformats).

DRM uses little endian.

> Departing from that would be more of a hindrance than a help, IMHO.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hello,

On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > (CC'ing Sakari and Hans)
> > 
> > Thank you for the patch.
> > 
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> index 8c2719efda2a..8ccabf5a30c4 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>  		.bpp = 32,
> >>  		.planes = 1,
> >>  		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_RGBX1010102,
> > 
> > Ah, here the format makes sense.
> > 
> >> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> > 
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> > 
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
> 
> V4L2 describes pixel formats based on how they appear in memory from the
> lowest to highest memory address.
> 
> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> in naming. I don't think we should hide that difference. And V4L2 has been
> quite consistent in following memory ordering in the naming (except possibly
> for some of the really old pixelformats).

We depart from that rule with at least the following RGB formats:

V4L2_PIX_FMT_XBGR32
V4L2_PIX_FMT_BGRX32
V4L2_PIX_FMT_ABGR32
V4L2_PIX_FMT_BGRA32

While the following formats follow the rule:

V4L2_PIX_FMT_RGB24
V4L2_PIX_FMT_BGR24
V4L2_PIX_FMT_XRGB32
V4L2_PIX_FMT_RGBX32
V4L2_PIX_FMT_RGBA32
V4L2_PIX_FMT_ARGB32

For 16-bit RGB formats, we name them based on the order in a 16-bit word
which is then stored in memory in little endian (except for the formats
explicitly defined as big-endian):

#define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
#define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
#define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
#define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
#define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
#define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
#define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
#define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
#define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
#define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
#define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
#define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
#define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
#define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
#define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
#define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */

I would thus argue that, at least for RGB formats, naming them based on
the byte order in memory isn't such a clear cut rule. 

> Departing from that would be more of a hindrance than a help, IMHO.
>
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_RGBA1010102,
> >> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_ARGB2101010,
> >> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >>  	}, {
> >>  		.fourcc = DRM_FORMAT_YVYU,
> >>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> >> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>  		.bpp = 24,
> >>  		.planes = 3,
> >>  		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_Y210,
> >> +		.v4l2 = V4L2_PIX_FMT_Y210,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 2,
> >>  	},
> > 
> > Any reason why you'd not adding Y212 support already ?
> > 
> >>  };
> >>  
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> index e465aef41585..6f3e109a4f80 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
> >>  	DRM_FORMAT_YVU444,
> >>  };
> >>  
> >> +/*
> >> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> >> + * formats and Y210 format.
> >> + */
> >> +static const u32 rcar_du_vsp_formats_gen4[] = {
> >> +	DRM_FORMAT_RGB332,
> >> +	DRM_FORMAT_ARGB4444,
> >> +	DRM_FORMAT_XRGB4444,
> >> +	DRM_FORMAT_ARGB1555,
> >> +	DRM_FORMAT_XRGB1555,
> >> +	DRM_FORMAT_RGB565,
> >> +	DRM_FORMAT_BGR888,
> >> +	DRM_FORMAT_RGB888,
> >> +	DRM_FORMAT_BGRA8888,
> >> +	DRM_FORMAT_BGRX8888,
> >> +	DRM_FORMAT_ARGB8888,
> >> +	DRM_FORMAT_XRGB8888,
> >> +	DRM_FORMAT_RGBX1010102,
> >> +	DRM_FORMAT_RGBA1010102,
> >> +	DRM_FORMAT_ARGB2101010,
> >> +	DRM_FORMAT_UYVY,
> >> +	DRM_FORMAT_YUYV,
> >> +	DRM_FORMAT_YVYU,
> >> +	DRM_FORMAT_NV12,
> >> +	DRM_FORMAT_NV21,
> >> +	DRM_FORMAT_NV16,
> >> +	DRM_FORMAT_NV61,
> >> +	DRM_FORMAT_YUV420,
> >> +	DRM_FORMAT_YVU420,
> >> +	DRM_FORMAT_YUV422,
> >> +	DRM_FORMAT_YVU422,
> >> +	DRM_FORMAT_YUV444,
> >> +	DRM_FORMAT_YVU444,
> >> +	DRM_FORMAT_Y210,
> >> +};
> >> +
> >>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
> >>  {
> >>  	struct rcar_du_vsp_plane_state *state =
> >> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> >>  					 ? DRM_PLANE_TYPE_PRIMARY
> >>  					 : DRM_PLANE_TYPE_OVERLAY;
> >>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> >> +		unsigned int num_formats;
> >> +		const u32 *formats;
> >> +
> >> +		if (rcdu->info->gen < 4) {
> >> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> >> +			formats = rcar_du_vsp_formats;
> >> +		} else {
> >> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> >> +			formats = rcar_du_vsp_formats_gen4;
> >> +		}
> >>  
> >>  		plane->vsp = vsp;
> >>  		plane->index = i;
> >>  
> >>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
> >>  					       crtcs, &rcar_du_vsp_plane_funcs,
> >> -					       rcar_du_vsp_formats,
> >> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> >> +					       formats, num_formats,
> >>  					       NULL, type, NULL);
> >>  		if (ret < 0)
> >>  			return ret;
> > 
> 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hello,

On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > (CC'ing Sakari and Hans)
> > 
> > Thank you for the patch.
> > 
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> index 8c2719efda2a..8ccabf5a30c4 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>  		.bpp = 32,
> >>  		.planes = 1,
> >>  		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_RGBX1010102,
> > 
> > Ah, here the format makes sense.
> > 
> >> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> > 
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> > 
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
> 
> V4L2 describes pixel formats based on how they appear in memory from the
> lowest to highest memory address.
> 
> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> in naming. I don't think we should hide that difference. And V4L2 has been
> quite consistent in following memory ordering in the naming (except possibly
> for some of the really old pixelformats).

We depart from that rule with at least the following RGB formats:

V4L2_PIX_FMT_XBGR32
V4L2_PIX_FMT_BGRX32
V4L2_PIX_FMT_ABGR32
V4L2_PIX_FMT_BGRA32

While the following formats follow the rule:

V4L2_PIX_FMT_RGB24
V4L2_PIX_FMT_BGR24
V4L2_PIX_FMT_XRGB32
V4L2_PIX_FMT_RGBX32
V4L2_PIX_FMT_RGBA32
V4L2_PIX_FMT_ARGB32

For 16-bit RGB formats, we name them based on the order in a 16-bit word
which is then stored in memory in little endian (except for the formats
explicitly defined as big-endian):

#define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
#define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
#define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
#define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
#define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
#define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
#define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
#define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
#define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
#define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
#define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
#define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
#define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
#define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
#define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
#define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */

I would thus argue that, at least for RGB formats, naming them based on
the byte order in memory isn't such a clear cut rule. 

> Departing from that would be more of a hindrance than a help, IMHO.
>
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_RGBA1010102,
> >> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_ARGB2101010,
> >> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 1,
> >>  	}, {
> >>  		.fourcc = DRM_FORMAT_YVYU,
> >>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> >> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>  		.bpp = 24,
> >>  		.planes = 3,
> >>  		.hsub = 1,
> >> +	}, {
> >> +		.fourcc = DRM_FORMAT_Y210,
> >> +		.v4l2 = V4L2_PIX_FMT_Y210,
> >> +		.bpp = 32,
> >> +		.planes = 1,
> >> +		.hsub = 2,
> >>  	},
> > 
> > Any reason why you'd not adding Y212 support already ?
> > 
> >>  };
> >>  
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> index e465aef41585..6f3e109a4f80 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
> >>  	DRM_FORMAT_YVU444,
> >>  };
> >>  
> >> +/*
> >> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> >> + * formats and Y210 format.
> >> + */
> >> +static const u32 rcar_du_vsp_formats_gen4[] = {
> >> +	DRM_FORMAT_RGB332,
> >> +	DRM_FORMAT_ARGB4444,
> >> +	DRM_FORMAT_XRGB4444,
> >> +	DRM_FORMAT_ARGB1555,
> >> +	DRM_FORMAT_XRGB1555,
> >> +	DRM_FORMAT_RGB565,
> >> +	DRM_FORMAT_BGR888,
> >> +	DRM_FORMAT_RGB888,
> >> +	DRM_FORMAT_BGRA8888,
> >> +	DRM_FORMAT_BGRX8888,
> >> +	DRM_FORMAT_ARGB8888,
> >> +	DRM_FORMAT_XRGB8888,
> >> +	DRM_FORMAT_RGBX1010102,
> >> +	DRM_FORMAT_RGBA1010102,
> >> +	DRM_FORMAT_ARGB2101010,
> >> +	DRM_FORMAT_UYVY,
> >> +	DRM_FORMAT_YUYV,
> >> +	DRM_FORMAT_YVYU,
> >> +	DRM_FORMAT_NV12,
> >> +	DRM_FORMAT_NV21,
> >> +	DRM_FORMAT_NV16,
> >> +	DRM_FORMAT_NV61,
> >> +	DRM_FORMAT_YUV420,
> >> +	DRM_FORMAT_YVU420,
> >> +	DRM_FORMAT_YUV422,
> >> +	DRM_FORMAT_YVU422,
> >> +	DRM_FORMAT_YUV444,
> >> +	DRM_FORMAT_YVU444,
> >> +	DRM_FORMAT_Y210,
> >> +};
> >> +
> >>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
> >>  {
> >>  	struct rcar_du_vsp_plane_state *state =
> >> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> >>  					 ? DRM_PLANE_TYPE_PRIMARY
> >>  					 : DRM_PLANE_TYPE_OVERLAY;
> >>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> >> +		unsigned int num_formats;
> >> +		const u32 *formats;
> >> +
> >> +		if (rcdu->info->gen < 4) {
> >> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> >> +			formats = rcar_du_vsp_formats;
> >> +		} else {
> >> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> >> +			formats = rcar_du_vsp_formats_gen4;
> >> +		}
> >>  
> >>  		plane->vsp = vsp;
> >>  		plane->index = i;
> >>  
> >>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
> >>  					       crtcs, &rcar_du_vsp_plane_funcs,
> >> -					       rcar_du_vsp_formats,
> >> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> >> +					       formats, num_formats,
> >>  					       NULL, type, NULL);
> >>  		if (ret < 0)
> >>  			return ret;
> > 
> 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> Hi Hans,
> 
> On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> index 8c2719efda2a..8ccabf5a30c4 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>              .bpp = 32,
>>>>              .planes = 1,
>>>>              .hsub = 1,
>>>> +    }, {
>>>> +            .fourcc = DRM_FORMAT_RGBX1010102,
>>>
>>> Ah, here the format makes sense.
>>>
>>>> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
>>>
>>> But this is horrible :-( Could we use the same names as DRM for new
>>> formats, when there is no conflict with existing V4L2 formats ?
>>>
>>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
>>> the format definitions.
>>
>> V4L2 describes pixel formats based on how they appear in memory from the
>> lowest to highest memory address.
> 
> So that means big endian?

Yes.

> 
>> If I am not mistaken, DRM uses the CPU order. So that explains the difference
>> in naming. I don't think we should hide that difference. And V4L2 has been
>> quite consistent in following memory ordering in the naming (except possibly
>> for some of the really old pixelformats).
> 
> DRM uses little endian.

So not CPU order, but always little endian order? I.e., on a big endian system
a given DRM_FORMAT_ would have the same memory layout as on a little endian
system?

Regards,

	Hans

> 
>> Departing from that would be more of a hindrance than a help, IMHO.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> Hi Hans,
> 
> On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> index 8c2719efda2a..8ccabf5a30c4 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>              .bpp = 32,
>>>>              .planes = 1,
>>>>              .hsub = 1,
>>>> +    }, {
>>>> +            .fourcc = DRM_FORMAT_RGBX1010102,
>>>
>>> Ah, here the format makes sense.
>>>
>>>> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
>>>
>>> But this is horrible :-( Could we use the same names as DRM for new
>>> formats, when there is no conflict with existing V4L2 formats ?
>>>
>>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
>>> the format definitions.
>>
>> V4L2 describes pixel formats based on how they appear in memory from the
>> lowest to highest memory address.
> 
> So that means big endian?

Yes.

> 
>> If I am not mistaken, DRM uses the CPU order. So that explains the difference
>> in naming. I don't think we should hide that difference. And V4L2 has been
>> quite consistent in following memory ordering in the naming (except possibly
>> for some of the really old pixelformats).
> 
> DRM uses little endian.

So not CPU order, but always little endian order? I.e., on a big endian system
a given DRM_FORMAT_ would have the same memory layout as on a little endian
system?

Regards,

	Hans

> 
>> Departing from that would be more of a hindrance than a help, IMHO.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 20/12/2022 10:18, Laurent Pinchart wrote:
> Hello,
> 
> On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> index 8c2719efda2a..8ccabf5a30c4 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>  		.bpp = 32,
>>>>  		.planes = 1,
>>>>  		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_RGBX1010102,
>>>
>>> Ah, here the format makes sense.
>>>
>>>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
>>>
>>> But this is horrible :-( Could we use the same names as DRM for new
>>> formats, when there is no conflict with existing V4L2 formats ?
>>>
>>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
>>> the format definitions.
>>
>> V4L2 describes pixel formats based on how they appear in memory from the
>> lowest to highest memory address.
>>
>> If I am not mistaken, DRM uses the CPU order. So that explains the difference
>> in naming. I don't think we should hide that difference. And V4L2 has been
>> quite consistent in following memory ordering in the naming (except possibly
>> for some of the really old pixelformats).
> 
> We depart from that rule with at least the following RGB formats:
> 
> V4L2_PIX_FMT_XBGR32
> V4L2_PIX_FMT_BGRX32
> V4L2_PIX_FMT_ABGR32
> V4L2_PIX_FMT_BGRA32
> 
> While the following formats follow the rule:
> 
> V4L2_PIX_FMT_RGB24
> V4L2_PIX_FMT_BGR24
> V4L2_PIX_FMT_XRGB32
> V4L2_PIX_FMT_RGBX32
> V4L2_PIX_FMT_RGBA32
> V4L2_PIX_FMT_ARGB32
> 
> For 16-bit RGB formats, we name them based on the order in a 16-bit word
> which is then stored in memory in little endian (except for the formats
> explicitly defined as big-endian):
> 
> #define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
> #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
> #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
> #define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
> #define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
> #define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
> #define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
> #define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
> #define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
> #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
> #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
> #define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
> #define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
> #define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
> #define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
> #define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
> #define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
> #define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */

Yes, these are all really old pixel formats :-)

> 
> I would thus argue that, at least for RGB formats, naming them based on
> the byte order in memory isn't such a clear cut rule. 
> 
>> Departing from that would be more of a hindrance than a help, IMHO.

Ideally we would unify the drm and v4l2 formats to new defines shared among
the two subsystems. I believe that was attempted some years back. In the end,
it was just decided to keep them separate, i.e. it wasn't worth the effort.

So unless someone wants to restart that idea, I think we should just stick to
what we have today, warts and all.

Regards,

	Hans

>>
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_RGBA1010102,
>>>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_ARGB2101010,
>>>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>>  	}, {
>>>>  		.fourcc = DRM_FORMAT_YVYU,
>>>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
>>>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>  		.bpp = 24,
>>>>  		.planes = 3,
>>>>  		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_Y210,
>>>> +		.v4l2 = V4L2_PIX_FMT_Y210,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 2,
>>>>  	},
>>>
>>> Any reason why you'd not adding Y212 support already ?
>>>
>>>>  };
>>>>  
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> index e465aef41585..6f3e109a4f80 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>>>>  	DRM_FORMAT_YVU444,
>>>>  };
>>>>  
>>>> +/*
>>>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
>>>> + * formats and Y210 format.
>>>> + */
>>>> +static const u32 rcar_du_vsp_formats_gen4[] = {
>>>> +	DRM_FORMAT_RGB332,
>>>> +	DRM_FORMAT_ARGB4444,
>>>> +	DRM_FORMAT_XRGB4444,
>>>> +	DRM_FORMAT_ARGB1555,
>>>> +	DRM_FORMAT_XRGB1555,
>>>> +	DRM_FORMAT_RGB565,
>>>> +	DRM_FORMAT_BGR888,
>>>> +	DRM_FORMAT_RGB888,
>>>> +	DRM_FORMAT_BGRA8888,
>>>> +	DRM_FORMAT_BGRX8888,
>>>> +	DRM_FORMAT_ARGB8888,
>>>> +	DRM_FORMAT_XRGB8888,
>>>> +	DRM_FORMAT_RGBX1010102,
>>>> +	DRM_FORMAT_RGBA1010102,
>>>> +	DRM_FORMAT_ARGB2101010,
>>>> +	DRM_FORMAT_UYVY,
>>>> +	DRM_FORMAT_YUYV,
>>>> +	DRM_FORMAT_YVYU,
>>>> +	DRM_FORMAT_NV12,
>>>> +	DRM_FORMAT_NV21,
>>>> +	DRM_FORMAT_NV16,
>>>> +	DRM_FORMAT_NV61,
>>>> +	DRM_FORMAT_YUV420,
>>>> +	DRM_FORMAT_YVU420,
>>>> +	DRM_FORMAT_YUV422,
>>>> +	DRM_FORMAT_YVU422,
>>>> +	DRM_FORMAT_YUV444,
>>>> +	DRM_FORMAT_YVU444,
>>>> +	DRM_FORMAT_Y210,
>>>> +};
>>>> +
>>>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>>>>  {
>>>>  	struct rcar_du_vsp_plane_state *state =
>>>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>>>>  					 ? DRM_PLANE_TYPE_PRIMARY
>>>>  					 : DRM_PLANE_TYPE_OVERLAY;
>>>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
>>>> +		unsigned int num_formats;
>>>> +		const u32 *formats;
>>>> +
>>>> +		if (rcdu->info->gen < 4) {
>>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
>>>> +			formats = rcar_du_vsp_formats;
>>>> +		} else {
>>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
>>>> +			formats = rcar_du_vsp_formats_gen4;
>>>> +		}
>>>>  
>>>>  		plane->vsp = vsp;
>>>>  		plane->index = i;
>>>>  
>>>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>>>>  					       crtcs, &rcar_du_vsp_plane_funcs,
>>>> -					       rcar_du_vsp_formats,
>>>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
>>>> +					       formats, num_formats,
>>>>  					       NULL, type, NULL);
>>>>  		if (ret < 0)
>>>>  			return ret;
>>>
>>
> 

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Hans Verkuil]

On 20/12/2022 10:18, Laurent Pinchart wrote:
> Hello,
> 
> On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
>>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
>>>>  2 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> index 8c2719efda2a..8ccabf5a30c4 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>  		.bpp = 32,
>>>>  		.planes = 1,
>>>>  		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_RGBX1010102,
>>>
>>> Ah, here the format makes sense.
>>>
>>>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
>>>
>>> But this is horrible :-( Could we use the same names as DRM for new
>>> formats, when there is no conflict with existing V4L2 formats ?
>>>
>>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
>>> the format definitions.
>>
>> V4L2 describes pixel formats based on how they appear in memory from the
>> lowest to highest memory address.
>>
>> If I am not mistaken, DRM uses the CPU order. So that explains the difference
>> in naming. I don't think we should hide that difference. And V4L2 has been
>> quite consistent in following memory ordering in the naming (except possibly
>> for some of the really old pixelformats).
> 
> We depart from that rule with at least the following RGB formats:
> 
> V4L2_PIX_FMT_XBGR32
> V4L2_PIX_FMT_BGRX32
> V4L2_PIX_FMT_ABGR32
> V4L2_PIX_FMT_BGRA32
> 
> While the following formats follow the rule:
> 
> V4L2_PIX_FMT_RGB24
> V4L2_PIX_FMT_BGR24
> V4L2_PIX_FMT_XRGB32
> V4L2_PIX_FMT_RGBX32
> V4L2_PIX_FMT_RGBA32
> V4L2_PIX_FMT_ARGB32
> 
> For 16-bit RGB formats, we name them based on the order in a 16-bit word
> which is then stored in memory in little endian (except for the formats
> explicitly defined as big-endian):
> 
> #define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
> #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
> #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
> #define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
> #define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
> #define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
> #define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
> #define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
> #define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
> #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
> #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
> #define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
> #define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
> #define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
> #define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
> #define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
> #define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
> #define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */

Yes, these are all really old pixel formats :-)

> 
> I would thus argue that, at least for RGB formats, naming them based on
> the byte order in memory isn't such a clear cut rule. 
> 
>> Departing from that would be more of a hindrance than a help, IMHO.

Ideally we would unify the drm and v4l2 formats to new defines shared among
the two subsystems. I believe that was attempted some years back. In the end,
it was just decided to keep them separate, i.e. it wasn't worth the effort.

So unless someone wants to restart that idea, I think we should just stick to
what we have today, warts and all.

Regards,

	Hans

>>
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_RGBA1010102,
>>>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_ARGB2101010,
>>>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 1,
>>>>  	}, {
>>>>  		.fourcc = DRM_FORMAT_YVYU,
>>>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
>>>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
>>>>  		.bpp = 24,
>>>>  		.planes = 3,
>>>>  		.hsub = 1,
>>>> +	}, {
>>>> +		.fourcc = DRM_FORMAT_Y210,
>>>> +		.v4l2 = V4L2_PIX_FMT_Y210,
>>>> +		.bpp = 32,
>>>> +		.planes = 1,
>>>> +		.hsub = 2,
>>>>  	},
>>>
>>> Any reason why you'd not adding Y212 support already ?
>>>
>>>>  };
>>>>  
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> index e465aef41585..6f3e109a4f80 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>>>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>>>>  	DRM_FORMAT_YVU444,
>>>>  };
>>>>  
>>>> +/*
>>>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
>>>> + * formats and Y210 format.
>>>> + */
>>>> +static const u32 rcar_du_vsp_formats_gen4[] = {
>>>> +	DRM_FORMAT_RGB332,
>>>> +	DRM_FORMAT_ARGB4444,
>>>> +	DRM_FORMAT_XRGB4444,
>>>> +	DRM_FORMAT_ARGB1555,
>>>> +	DRM_FORMAT_XRGB1555,
>>>> +	DRM_FORMAT_RGB565,
>>>> +	DRM_FORMAT_BGR888,
>>>> +	DRM_FORMAT_RGB888,
>>>> +	DRM_FORMAT_BGRA8888,
>>>> +	DRM_FORMAT_BGRX8888,
>>>> +	DRM_FORMAT_ARGB8888,
>>>> +	DRM_FORMAT_XRGB8888,
>>>> +	DRM_FORMAT_RGBX1010102,
>>>> +	DRM_FORMAT_RGBA1010102,
>>>> +	DRM_FORMAT_ARGB2101010,
>>>> +	DRM_FORMAT_UYVY,
>>>> +	DRM_FORMAT_YUYV,
>>>> +	DRM_FORMAT_YVYU,
>>>> +	DRM_FORMAT_NV12,
>>>> +	DRM_FORMAT_NV21,
>>>> +	DRM_FORMAT_NV16,
>>>> +	DRM_FORMAT_NV61,
>>>> +	DRM_FORMAT_YUV420,
>>>> +	DRM_FORMAT_YVU420,
>>>> +	DRM_FORMAT_YUV422,
>>>> +	DRM_FORMAT_YVU422,
>>>> +	DRM_FORMAT_YUV444,
>>>> +	DRM_FORMAT_YVU444,
>>>> +	DRM_FORMAT_Y210,
>>>> +};
>>>> +
>>>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>>>>  {
>>>>  	struct rcar_du_vsp_plane_state *state =
>>>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>>>>  					 ? DRM_PLANE_TYPE_PRIMARY
>>>>  					 : DRM_PLANE_TYPE_OVERLAY;
>>>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
>>>> +		unsigned int num_formats;
>>>> +		const u32 *formats;
>>>> +
>>>> +		if (rcdu->info->gen < 4) {
>>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
>>>> +			formats = rcar_du_vsp_formats;
>>>> +		} else {
>>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
>>>> +			formats = rcar_du_vsp_formats_gen4;
>>>> +		}
>>>>  
>>>>  		plane->vsp = vsp;
>>>>  		plane->index = i;
>>>>  
>>>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
>>>>  					       crtcs, &rcar_du_vsp_plane_funcs,
>>>> -					       rcar_du_vsp_formats,
>>>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
>>>> +					       formats, num_formats,
>>>>  					       NULL, type, NULL);
>>>>  		if (ret < 0)
>>>>  			return ret;
>>>
>>
> 

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Geert Uytterhoeven]

Hi Hans,

On Tue, Dec 20, 2022 at 10:22 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> > On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> (CC'ing Sakari and Hans)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>>> ---
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>>>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> index 8c2719efda2a..8ccabf5a30c4 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>              .bpp = 32,
> >>>>              .planes = 1,
> >>>>              .hsub = 1,
> >>>> +    }, {
> >>>> +            .fourcc = DRM_FORMAT_RGBX1010102,
> >>>
> >>> Ah, here the format makes sense.
> >>>
> >>>> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >>>
> >>> But this is horrible :-( Could we use the same names as DRM for new
> >>> formats, when there is no conflict with existing V4L2 formats ?
> >>>
> >>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> >>> the format definitions.
> >>
> >> V4L2 describes pixel formats based on how they appear in memory from the
> >> lowest to highest memory address.
> >
> > So that means big endian?
>
> Yes.
>
> >> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> >> in naming. I don't think we should hide that difference. And V4L2 has been
> >> quite consistent in following memory ordering in the naming (except possibly
> >> for some of the really old pixelformats).
> >
> > DRM uses little endian.
>
> So not CPU order, but always little endian order? I.e., on a big endian system
> a given DRM_FORMAT_ would have the same memory layout as on a little endian
> system?

Indeed. Big-endian formats must set the DRM_FORMAT_BIG_ENDIAN flag:

    #define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian
instead of little endian */

unless the big-endian format has a standard (little-endian) equivalent:

Old PPC drivers may violate that, so there is some quirk handling...

/*
 * DRM formats are little endian.  Define host endian variants for the
 * most common formats here, to reduce the #ifdefs needed in drivers.
 *
 * Note that the DRM_FORMAT_BIG_ENDIAN flag should only be used in
 * case the format can't be specified otherwise, so we don't end up
 * with two values describing the same format.
 */
#ifdef __BIG_ENDIAN
# define DRM_FORMAT_HOST_XRGB1555     (DRM_FORMAT_XRGB1555         |    \
                                       DRM_FORMAT_BIG_ENDIAN)
# define DRM_FORMAT_HOST_RGB565       (DRM_FORMAT_RGB565           |    \
                                       DRM_FORMAT_BIG_ENDIAN)
# define DRM_FORMAT_HOST_XRGB8888     DRM_FORMAT_BGRX8888
# define DRM_FORMAT_HOST_ARGB8888     DRM_FORMAT_BGRA8888
#else
# define DRM_FORMAT_HOST_XRGB1555     DRM_FORMAT_XRGB1555
# define DRM_FORMAT_HOST_RGB565       DRM_FORMAT_RGB565
# define DRM_FORMAT_HOST_XRGB8888     DRM_FORMAT_XRGB8888
# define DRM_FORMAT_HOST_ARGB8888     DRM_FORMAT_ARGB8888
#endif

However, given the number of bugs related to big-endian formats,
I doubt DRM has any real use on big-endian hardware (i.e. not
counting hobbyists trying to migrate from fbdev to DRM ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Geert Uytterhoeven]

Hi Hans,

On Tue, Dec 20, 2022 at 10:22 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> > On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> (CC'ing Sakari and Hans)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>>> ---
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>>>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> index 8c2719efda2a..8ccabf5a30c4 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>              .bpp = 32,
> >>>>              .planes = 1,
> >>>>              .hsub = 1,
> >>>> +    }, {
> >>>> +            .fourcc = DRM_FORMAT_RGBX1010102,
> >>>
> >>> Ah, here the format makes sense.
> >>>
> >>>> +            .v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >>>
> >>> But this is horrible :-( Could we use the same names as DRM for new
> >>> formats, when there is no conflict with existing V4L2 formats ?
> >>>
> >>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> >>> the format definitions.
> >>
> >> V4L2 describes pixel formats based on how they appear in memory from the
> >> lowest to highest memory address.
> >
> > So that means big endian?
>
> Yes.
>
> >> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> >> in naming. I don't think we should hide that difference. And V4L2 has been
> >> quite consistent in following memory ordering in the naming (except possibly
> >> for some of the really old pixelformats).
> >
> > DRM uses little endian.
>
> So not CPU order, but always little endian order? I.e., on a big endian system
> a given DRM_FORMAT_ would have the same memory layout as on a little endian
> system?

Indeed. Big-endian formats must set the DRM_FORMAT_BIG_ENDIAN flag:

    #define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian
instead of little endian */

unless the big-endian format has a standard (little-endian) equivalent:

Old PPC drivers may violate that, so there is some quirk handling...

/*
 * DRM formats are little endian.  Define host endian variants for the
 * most common formats here, to reduce the #ifdefs needed in drivers.
 *
 * Note that the DRM_FORMAT_BIG_ENDIAN flag should only be used in
 * case the format can't be specified otherwise, so we don't end up
 * with two values describing the same format.
 */
#ifdef __BIG_ENDIAN
# define DRM_FORMAT_HOST_XRGB1555     (DRM_FORMAT_XRGB1555         |    \
                                       DRM_FORMAT_BIG_ENDIAN)
# define DRM_FORMAT_HOST_RGB565       (DRM_FORMAT_RGB565           |    \
                                       DRM_FORMAT_BIG_ENDIAN)
# define DRM_FORMAT_HOST_XRGB8888     DRM_FORMAT_BGRX8888
# define DRM_FORMAT_HOST_ARGB8888     DRM_FORMAT_BGRA8888
#else
# define DRM_FORMAT_HOST_XRGB1555     DRM_FORMAT_XRGB1555
# define DRM_FORMAT_HOST_RGB565       DRM_FORMAT_RGB565
# define DRM_FORMAT_HOST_XRGB8888     DRM_FORMAT_XRGB8888
# define DRM_FORMAT_HOST_ARGB8888     DRM_FORMAT_ARGB8888
#endif

However, given the number of bugs related to big-endian formats,
I doubt DRM has any real use on big-endian hardware (i.e. not
counting hobbyists trying to migrate from fbdev to DRM ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Sakari Ailus]

Hi Laurent,

On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
> 
> (CC'ing Sakari and Hans)
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >  2 files changed, 71 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 8c2719efda2a..8ccabf5a30c4 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >  		.bpp = 32,
> >  		.planes = 1,
> >  		.hsub = 1,
> > +	}, {
> > +		.fourcc = DRM_FORMAT_RGBX1010102,
> 
> Ah, here the format makes sense.
> 
> > +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> 
> But this is horrible :-( Could we use the same names as DRM for new
> formats, when there is no conflict with existing V4L2 formats ?
> 
> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> the format definitions.

I think it'd be good to have only one set of definitions.

Can we can sort the endianness question in a reasonable way?

Also new Bayer formats will probably be still needed on V4L2 side but will
they be relevant for DRM? I suppose that would mean new DRM format for
each pixel order, too? Or can we think of something smarter that would
still work reasonably with existing formats?

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Sakari Ailus]

Hi Laurent,

On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
> 
> (CC'ing Sakari and Hans)
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >  2 files changed, 71 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 8c2719efda2a..8ccabf5a30c4 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >  		.bpp = 32,
> >  		.planes = 1,
> >  		.hsub = 1,
> > +	}, {
> > +		.fourcc = DRM_FORMAT_RGBX1010102,
> 
> Ah, here the format makes sense.
> 
> > +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> 
> But this is horrible :-( Could we use the same names as DRM for new
> formats, when there is no conflict with existing V4L2 formats ?
> 
> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> the format definitions.

I think it'd be good to have only one set of definitions.

Can we can sort the endianness question in a reasonable way?

Also new Bayer formats will probably be still needed on V4L2 side but will
they be relevant for DRM? I suppose that would mean new DRM format for
each pixel order, too? Or can we think of something smarter that would
still work reasonably with existing formats?

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Hans,

On Tue, Dec 20, 2022 at 10:26:35AM +0100, Hans Verkuil wrote:
> On 20/12/2022 10:18, Laurent Pinchart wrote:
> > On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> (CC'ing Sakari and Hans)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>>> ---
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>>>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> index 8c2719efda2a..8ccabf5a30c4 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>  		.bpp = 32,
> >>>>  		.planes = 1,
> >>>>  		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_RGBX1010102,
> >>>
> >>> Ah, here the format makes sense.
> >>>
> >>>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >>>
> >>> But this is horrible :-( Could we use the same names as DRM for new
> >>> formats, when there is no conflict with existing V4L2 formats ?
> >>>
> >>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> >>> the format definitions.
> >>
> >> V4L2 describes pixel formats based on how they appear in memory from the
> >> lowest to highest memory address.
> >>
> >> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> >> in naming. I don't think we should hide that difference. And V4L2 has been
> >> quite consistent in following memory ordering in the naming (except possibly
> >> for some of the really old pixelformats).
> > 
> > We depart from that rule with at least the following RGB formats:
> > 
> > V4L2_PIX_FMT_XBGR32
> > V4L2_PIX_FMT_BGRX32
> > V4L2_PIX_FMT_ABGR32
> > V4L2_PIX_FMT_BGRA32
> > 
> > While the following formats follow the rule:
> > 
> > V4L2_PIX_FMT_RGB24
> > V4L2_PIX_FMT_BGR24
> > V4L2_PIX_FMT_XRGB32
> > V4L2_PIX_FMT_RGBX32
> > V4L2_PIX_FMT_RGBA32
> > V4L2_PIX_FMT_ARGB32
> > 
> > For 16-bit RGB formats, we name them based on the order in a 16-bit word
> > which is then stored in memory in little endian (except for the formats
> > explicitly defined as big-endian):
> > 
> > #define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
> > #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
> > #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
> > #define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
> > #define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
> > #define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
> > #define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
> > #define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
> > #define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
> > #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
> > #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
> > #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
> > #define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
> > #define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
> > #define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
> > #define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
> > #define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
> > #define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
> > #define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */
> 
> Yes, these are all really old pixel formats :-)

Which ones do you consider new then ? :-) Even if we look at the 24-bit
and 32-bit RGB formats only (which are not very recent), its 40%/60%.

> > I would thus argue that, at least for RGB formats, naming them based on
> > the byte order in memory isn't such a clear cut rule. 
> > 
> >> Departing from that would be more of a hindrance than a help, IMHO.
> 
> Ideally we would unify the drm and v4l2 formats to new defines shared among
> the two subsystems. I believe that was attempted some years back. In the end,
> it was just decided to keep them separate, i.e. it wasn't worth the effort.
> 
> So unless someone wants to restart that idea, I think we should just stick to
> what we have today, warts and all.

Maxime proposed that and submitted an RFC If I recall correctly. I
really liked the idea, but it was shot down on maintenance issues (again
if I recall correctly) with concerns that the media tree would depend on
code outside of its direct control when adding new formats.

Still, even if we don't share any code, I think it's worth making new
formats identical between V4L2 and DRM (as in having the same 4CC value
and the same macro name, excluding the prefix, for the same format).

> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_RGBA1010102,
> >>>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_ARGB2101010,
> >>>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>>  	}, {
> >>>>  		.fourcc = DRM_FORMAT_YVYU,
> >>>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> >>>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>  		.bpp = 24,
> >>>>  		.planes = 3,
> >>>>  		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_Y210,
> >>>> +		.v4l2 = V4L2_PIX_FMT_Y210,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 2,
> >>>>  	},
> >>>
> >>> Any reason why you'd not adding Y212 support already ?
> >>>
> >>>>  };
> >>>>  
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> index e465aef41585..6f3e109a4f80 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
> >>>>  	DRM_FORMAT_YVU444,
> >>>>  };
> >>>>  
> >>>> +/*
> >>>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> >>>> + * formats and Y210 format.
> >>>> + */
> >>>> +static const u32 rcar_du_vsp_formats_gen4[] = {
> >>>> +	DRM_FORMAT_RGB332,
> >>>> +	DRM_FORMAT_ARGB4444,
> >>>> +	DRM_FORMAT_XRGB4444,
> >>>> +	DRM_FORMAT_ARGB1555,
> >>>> +	DRM_FORMAT_XRGB1555,
> >>>> +	DRM_FORMAT_RGB565,
> >>>> +	DRM_FORMAT_BGR888,
> >>>> +	DRM_FORMAT_RGB888,
> >>>> +	DRM_FORMAT_BGRA8888,
> >>>> +	DRM_FORMAT_BGRX8888,
> >>>> +	DRM_FORMAT_ARGB8888,
> >>>> +	DRM_FORMAT_XRGB8888,
> >>>> +	DRM_FORMAT_RGBX1010102,
> >>>> +	DRM_FORMAT_RGBA1010102,
> >>>> +	DRM_FORMAT_ARGB2101010,
> >>>> +	DRM_FORMAT_UYVY,
> >>>> +	DRM_FORMAT_YUYV,
> >>>> +	DRM_FORMAT_YVYU,
> >>>> +	DRM_FORMAT_NV12,
> >>>> +	DRM_FORMAT_NV21,
> >>>> +	DRM_FORMAT_NV16,
> >>>> +	DRM_FORMAT_NV61,
> >>>> +	DRM_FORMAT_YUV420,
> >>>> +	DRM_FORMAT_YVU420,
> >>>> +	DRM_FORMAT_YUV422,
> >>>> +	DRM_FORMAT_YVU422,
> >>>> +	DRM_FORMAT_YUV444,
> >>>> +	DRM_FORMAT_YVU444,
> >>>> +	DRM_FORMAT_Y210,
> >>>> +};
> >>>> +
> >>>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
> >>>>  {
> >>>>  	struct rcar_du_vsp_plane_state *state =
> >>>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> >>>>  					 ? DRM_PLANE_TYPE_PRIMARY
> >>>>  					 : DRM_PLANE_TYPE_OVERLAY;
> >>>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> >>>> +		unsigned int num_formats;
> >>>> +		const u32 *formats;
> >>>> +
> >>>> +		if (rcdu->info->gen < 4) {
> >>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> >>>> +			formats = rcar_du_vsp_formats;
> >>>> +		} else {
> >>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> >>>> +			formats = rcar_du_vsp_formats_gen4;
> >>>> +		}
> >>>>  
> >>>>  		plane->vsp = vsp;
> >>>>  		plane->index = i;
> >>>>  
> >>>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
> >>>>  					       crtcs, &rcar_du_vsp_plane_funcs,
> >>>> -					       rcar_du_vsp_formats,
> >>>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> >>>> +					       formats, num_formats,
> >>>>  					       NULL, type, NULL);
> >>>>  		if (ret < 0)
> >>>>  			return ret;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Hans,

On Tue, Dec 20, 2022 at 10:26:35AM +0100, Hans Verkuil wrote:
> On 20/12/2022 10:18, Laurent Pinchart wrote:
> > On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> (CC'ing Sakari and Hans)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >>>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>>> ---
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> >>>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> >>>>  2 files changed, 71 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> index 8c2719efda2a..8ccabf5a30c4 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>>> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>  		.bpp = 32,
> >>>>  		.planes = 1,
> >>>>  		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_RGBX1010102,
> >>>
> >>> Ah, here the format makes sense.
> >>>
> >>>> +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> >>>
> >>> But this is horrible :-( Could we use the same names as DRM for new
> >>> formats, when there is no conflict with existing V4L2 formats ?
> >>>
> >>> Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> >>> the format definitions.
> >>
> >> V4L2 describes pixel formats based on how they appear in memory from the
> >> lowest to highest memory address.
> >>
> >> If I am not mistaken, DRM uses the CPU order. So that explains the difference
> >> in naming. I don't think we should hide that difference. And V4L2 has been
> >> quite consistent in following memory ordering in the naming (except possibly
> >> for some of the really old pixelformats).
> > 
> > We depart from that rule with at least the following RGB formats:
> > 
> > V4L2_PIX_FMT_XBGR32
> > V4L2_PIX_FMT_BGRX32
> > V4L2_PIX_FMT_ABGR32
> > V4L2_PIX_FMT_BGRA32
> > 
> > While the following formats follow the rule:
> > 
> > V4L2_PIX_FMT_RGB24
> > V4L2_PIX_FMT_BGR24
> > V4L2_PIX_FMT_XRGB32
> > V4L2_PIX_FMT_RGBX32
> > V4L2_PIX_FMT_RGBA32
> > V4L2_PIX_FMT_ARGB32
> > 
> > For 16-bit RGB formats, we name them based on the order in a 16-bit word
> > which is then stored in memory in little endian (except for the formats
> > explicitly defined as big-endian):
> > 
> > #define V4L2_PIX_FMT_RGB444  v4l2_fourcc('R', '4', '4', '4') /* 16  xxxxrrrr ggggbbbb */
> > #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16  aaaarrrr ggggbbbb */
> > #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16  xxxxrrrr ggggbbbb */
> > #define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16  rrrrgggg bbbbaaaa */
> > #define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16  rrrrgggg bbbbxxxx */
> > #define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16  aaaabbbb ggggrrrr */
> > #define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16  xxxxbbbb ggggrrrr */
> > #define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('G', 'A', '1', '2') /* 16  bbbbgggg rrrraaaa */
> > #define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16  bbbbgggg rrrrxxxx */
> > #define V4L2_PIX_FMT_RGB555  v4l2_fourcc('R', 'G', 'B', 'O') /* 16  RGB-5-5-5     */
> > #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16  ARGB-1-5-5-5  */
> > #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16  XRGB-1-5-5-5  */
> > #define V4L2_PIX_FMT_RGBA555 v4l2_fourcc('R', 'A', '1', '5') /* 16  RGBA-5-5-5-1  */
> > #define V4L2_PIX_FMT_RGBX555 v4l2_fourcc('R', 'X', '1', '5') /* 16  RGBX-5-5-5-1  */
> > #define V4L2_PIX_FMT_ABGR555 v4l2_fourcc('A', 'B', '1', '5') /* 16  ABGR-1-5-5-5  */
> > #define V4L2_PIX_FMT_XBGR555 v4l2_fourcc('X', 'B', '1', '5') /* 16  XBGR-1-5-5-5  */
> > #define V4L2_PIX_FMT_BGRA555 v4l2_fourcc('B', 'A', '1', '5') /* 16  BGRA-5-5-5-1  */
> > #define V4L2_PIX_FMT_BGRX555 v4l2_fourcc('B', 'X', '1', '5') /* 16  BGRX-5-5-5-1  */
> > #define V4L2_PIX_FMT_RGB565  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */
> 
> Yes, these are all really old pixel formats :-)

Which ones do you consider new then ? :-) Even if we look at the 24-bit
and 32-bit RGB formats only (which are not very recent), its 40%/60%.

> > I would thus argue that, at least for RGB formats, naming them based on
> > the byte order in memory isn't such a clear cut rule. 
> > 
> >> Departing from that would be more of a hindrance than a help, IMHO.
> 
> Ideally we would unify the drm and v4l2 formats to new defines shared among
> the two subsystems. I believe that was attempted some years back. In the end,
> it was just decided to keep them separate, i.e. it wasn't worth the effort.
> 
> So unless someone wants to restart that idea, I think we should just stick to
> what we have today, warts and all.

Maxime proposed that and submitted an RFC If I recall correctly. I
really liked the idea, but it was shot down on maintenance issues (again
if I recall correctly) with concerns that the media tree would depend on
code outside of its direct control when adding new formats.

Still, even if we don't share any code, I think it's worth making new
formats identical between V4L2 and DRM (as in having the same 4CC value
and the same macro name, excluding the prefix, for the same format).

> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_RGBA1010102,
> >>>> +		.v4l2 = V4L2_PIX_FMT_ABGR2101010,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_ARGB2101010,
> >>>> +		.v4l2 = V4L2_PIX_FMT_BGRA1010102,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 1,
> >>>>  	}, {
> >>>>  		.fourcc = DRM_FORMAT_YVYU,
> >>>>  		.v4l2 = V4L2_PIX_FMT_YVYU,
> >>>> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> >>>>  		.bpp = 24,
> >>>>  		.planes = 3,
> >>>>  		.hsub = 1,
> >>>> +	}, {
> >>>> +		.fourcc = DRM_FORMAT_Y210,
> >>>> +		.v4l2 = V4L2_PIX_FMT_Y210,
> >>>> +		.bpp = 32,
> >>>> +		.planes = 1,
> >>>> +		.hsub = 2,
> >>>>  	},
> >>>
> >>> Any reason why you'd not adding Y212 support already ?
> >>>
> >>>>  };
> >>>>  
> >>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> index e465aef41585..6f3e109a4f80 100644
> >>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >>>> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
> >>>>  	DRM_FORMAT_YVU444,
> >>>>  };
> >>>>  
> >>>> +/*
> >>>> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> >>>> + * formats and Y210 format.
> >>>> + */
> >>>> +static const u32 rcar_du_vsp_formats_gen4[] = {
> >>>> +	DRM_FORMAT_RGB332,
> >>>> +	DRM_FORMAT_ARGB4444,
> >>>> +	DRM_FORMAT_XRGB4444,
> >>>> +	DRM_FORMAT_ARGB1555,
> >>>> +	DRM_FORMAT_XRGB1555,
> >>>> +	DRM_FORMAT_RGB565,
> >>>> +	DRM_FORMAT_BGR888,
> >>>> +	DRM_FORMAT_RGB888,
> >>>> +	DRM_FORMAT_BGRA8888,
> >>>> +	DRM_FORMAT_BGRX8888,
> >>>> +	DRM_FORMAT_ARGB8888,
> >>>> +	DRM_FORMAT_XRGB8888,
> >>>> +	DRM_FORMAT_RGBX1010102,
> >>>> +	DRM_FORMAT_RGBA1010102,
> >>>> +	DRM_FORMAT_ARGB2101010,
> >>>> +	DRM_FORMAT_UYVY,
> >>>> +	DRM_FORMAT_YUYV,
> >>>> +	DRM_FORMAT_YVYU,
> >>>> +	DRM_FORMAT_NV12,
> >>>> +	DRM_FORMAT_NV21,
> >>>> +	DRM_FORMAT_NV16,
> >>>> +	DRM_FORMAT_NV61,
> >>>> +	DRM_FORMAT_YUV420,
> >>>> +	DRM_FORMAT_YVU420,
> >>>> +	DRM_FORMAT_YUV422,
> >>>> +	DRM_FORMAT_YVU422,
> >>>> +	DRM_FORMAT_YUV444,
> >>>> +	DRM_FORMAT_YVU444,
> >>>> +	DRM_FORMAT_Y210,
> >>>> +};
> >>>> +
> >>>>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
> >>>>  {
> >>>>  	struct rcar_du_vsp_plane_state *state =
> >>>> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> >>>>  					 ? DRM_PLANE_TYPE_PRIMARY
> >>>>  					 : DRM_PLANE_TYPE_OVERLAY;
> >>>>  		struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> >>>> +		unsigned int num_formats;
> >>>> +		const u32 *formats;
> >>>> +
> >>>> +		if (rcdu->info->gen < 4) {
> >>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> >>>> +			formats = rcar_du_vsp_formats;
> >>>> +		} else {
> >>>> +			num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> >>>> +			formats = rcar_du_vsp_formats_gen4;
> >>>> +		}
> >>>>  
> >>>>  		plane->vsp = vsp;
> >>>>  		plane->index = i;
> >>>>  
> >>>>  		ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
> >>>>  					       crtcs, &rcar_du_vsp_plane_funcs,
> >>>> -					       rcar_du_vsp_formats,
> >>>> -					       ARRAY_SIZE(rcar_du_vsp_formats),
> >>>> +					       formats, num_formats,
> >>>>  					       NULL, type, NULL);
> >>>>  		if (ret < 0)
> >>>>  			return ret;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Sakari,

On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > > 
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > > ---
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> > >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> > >  2 files changed, 71 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 8c2719efda2a..8ccabf5a30c4 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> > >  		.bpp = 32,
> > >  		.planes = 1,
> > >  		.hsub = 1,
> > > +	}, {
> > > +		.fourcc = DRM_FORMAT_RGBX1010102,
> > 
> > Ah, here the format makes sense.
> > 
> > > +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> > 
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> > 
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
> 
> I think it'd be good to have only one set of definitions.
> 
> Can we can sort the endianness question in a reasonable way?

It's really a matter of macro names only in this case, so it's "just" up
to us to decide what we want to do. Hans' argument is that we would then
depart from the general V4L2 rule, and thus create confusion, but I
don't think there's such a clear cut rule in the first place and
confusion is there already. Having common definitions for new formats
would, I think, reduce confusion.

> Also new Bayer formats will probably be still needed on V4L2 side but will
> they be relevant for DRM? I suppose that would mean new DRM format for
> each pixel order, too? Or can we think of something smarter that would
> still work reasonably with existing formats?

We use DRM 4CCs in the libcamera public API, and the DRM maintainers
have agreed to add DRM 4CCs for formats that are used by cameras only,
such as MJPEG for instance, that's hardly useful for displays. The same
holds true for Bayer formats, and we use DRM modifiers to specify the
packing instead of defining different 4CCs. I'd like to do something
similar for the Bayer pattern, although specifying it out-of-band may be
even better.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Sakari,

On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > > 
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > > ---
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> > >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> > >  2 files changed, 71 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 8c2719efda2a..8ccabf5a30c4 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> > >  		.bpp = 32,
> > >  		.planes = 1,
> > >  		.hsub = 1,
> > > +	}, {
> > > +		.fourcc = DRM_FORMAT_RGBX1010102,
> > 
> > Ah, here the format makes sense.
> > 
> > > +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> > 
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> > 
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
> 
> I think it'd be good to have only one set of definitions.
> 
> Can we can sort the endianness question in a reasonable way?

It's really a matter of macro names only in this case, so it's "just" up
to us to decide what we want to do. Hans' argument is that we would then
depart from the general V4L2 rule, and thus create confusion, but I
don't think there's such a clear cut rule in the first place and
confusion is there already. Having common definitions for new formats
would, I think, reduce confusion.

> Also new Bayer formats will probably be still needed on V4L2 side but will
> they be relevant for DRM? I suppose that would mean new DRM format for
> each pixel order, too? Or can we think of something smarter that would
> still work reasonably with existing formats?

We use DRM 4CCs in the libcamera public API, and the DRM maintainers
have agreed to add DRM 4CCs for formats that are used by cameras only,
such as MJPEG for instance, that's hardly useful for displays. The same
holds true for Bayer formats, and we use DRM modifiers to specify the
packing instead of defining different 4CCs. I'd like to do something
similar for the Bayer pattern, although specifying it out-of-band may be
even better.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Tomi Valkeinen]

On 19/12/2022 21:10, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
>> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>   .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>>   drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>>   include/uapi/linux/videodev2.h                |   3 +
>>   3 files changed, 200 insertions(+)
>>
>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> index 30f51cd33f99..de78cd2dcd73 100644
>> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>>       \normalsize
>>   
>>   
>> +10 Bits Per Component
>> +=====================
>> +
>> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
>> +bytes. They are named based on the order of the RGB components as seen in a
>> +32-bit word, which is then stored in memory in little endian byte order
>> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
>> +number of bits for each component.
>> +
>> +.. raw:: latex
>> +
>> +    \begingroup
>> +    \tiny
>> +    \setlength{\tabcolsep}{2pt}
>> +
>> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
>> +
>> +
>> +.. flat-table:: RGB Formats 10 Bits Per Color Component
>> +    :header-rows:  2
>> +    :stub-columns: 0
>> +
>> +    * - Identifier
>> +      - Code
>> +      - :cspan:`7` Byte 0 in memory
>> +      - :cspan:`7` Byte 1
>> +      - :cspan:`7` Byte 2
>> +      - :cspan:`7` Byte 3
>> +    * -
>> +      -
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +    * .. _V4L2-PIX-FMT-XBGR2101010:
>> +
>> +      - ``V4L2_PIX_FMT_XBGR2101010``
>> +      - 'RX30'
>> +
>> +      - b\ :sub:`5`
>> +      - b\ :sub:`4`
>> +      - b\ :sub:`3`
>> +      - b\ :sub:`2`
>> +      - b\ :sub:`1`
>> +      - b\ :sub:`0`
>> +      - x
>> +      - x
>> +
>> +      - g\ :sub:`3`
>> +      - g\ :sub:`2`
>> +      - g\ :sub:`1`
>> +      - g\ :sub:`0`
>> +      - b\ :sub:`9`
>> +      - b\ :sub:`8`
>> +      - b\ :sub:`7`
>> +      - b\ :sub:`6`
>> +
>> +      - r\ :sub:`1`
>> +      - r\ :sub:`0`
>> +      - g\ :sub:`9`
>> +      - g\ :sub:`8`
>> +      - g\ :sub:`7`
>> +      - g\ :sub:`6`
>> +      - g\ :sub:`5`
>> +      - g\ :sub:`4`
>> +
>> +      - r\ :sub:`9`
>> +      - r\ :sub:`8`
>> +      - r\ :sub:`7`
>> +      - r\ :sub:`6`
>> +      - r\ :sub:`5`
>> +      - r\ :sub:`4`
>> +      - r\ :sub:`3`
>> +      - r\ :sub:`2`
>> +      -
> 
> This doesn't match the text above. This would be RGBX2101010. I'm not
> sure which format you want, so I don't know if it's the documentation or
> the format name that is incorrect. The next two formats also seem
> incorrect to me.

Right, the text should say big endian instead of little endian.

  Tomi

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Tomi Valkeinen]

On 19/12/2022 21:10, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
>> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>   .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>>   drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>>   include/uapi/linux/videodev2.h                |   3 +
>>   3 files changed, 200 insertions(+)
>>
>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> index 30f51cd33f99..de78cd2dcd73 100644
>> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>>       \normalsize
>>   
>>   
>> +10 Bits Per Component
>> +=====================
>> +
>> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
>> +bytes. They are named based on the order of the RGB components as seen in a
>> +32-bit word, which is then stored in memory in little endian byte order
>> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
>> +number of bits for each component.
>> +
>> +.. raw:: latex
>> +
>> +    \begingroup
>> +    \tiny
>> +    \setlength{\tabcolsep}{2pt}
>> +
>> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
>> +
>> +
>> +.. flat-table:: RGB Formats 10 Bits Per Color Component
>> +    :header-rows:  2
>> +    :stub-columns: 0
>> +
>> +    * - Identifier
>> +      - Code
>> +      - :cspan:`7` Byte 0 in memory
>> +      - :cspan:`7` Byte 1
>> +      - :cspan:`7` Byte 2
>> +      - :cspan:`7` Byte 3
>> +    * -
>> +      -
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +
>> +      - 7
>> +      - 6
>> +      - 5
>> +      - 4
>> +      - 3
>> +      - 2
>> +      - 1
>> +      - 0
>> +    * .. _V4L2-PIX-FMT-XBGR2101010:
>> +
>> +      - ``V4L2_PIX_FMT_XBGR2101010``
>> +      - 'RX30'
>> +
>> +      - b\ :sub:`5`
>> +      - b\ :sub:`4`
>> +      - b\ :sub:`3`
>> +      - b\ :sub:`2`
>> +      - b\ :sub:`1`
>> +      - b\ :sub:`0`
>> +      - x
>> +      - x
>> +
>> +      - g\ :sub:`3`
>> +      - g\ :sub:`2`
>> +      - g\ :sub:`1`
>> +      - g\ :sub:`0`
>> +      - b\ :sub:`9`
>> +      - b\ :sub:`8`
>> +      - b\ :sub:`7`
>> +      - b\ :sub:`6`
>> +
>> +      - r\ :sub:`1`
>> +      - r\ :sub:`0`
>> +      - g\ :sub:`9`
>> +      - g\ :sub:`8`
>> +      - g\ :sub:`7`
>> +      - g\ :sub:`6`
>> +      - g\ :sub:`5`
>> +      - g\ :sub:`4`
>> +
>> +      - r\ :sub:`9`
>> +      - r\ :sub:`8`
>> +      - r\ :sub:`7`
>> +      - r\ :sub:`6`
>> +      - r\ :sub:`5`
>> +      - r\ :sub:`4`
>> +      - r\ :sub:`3`
>> +      - r\ :sub:`2`
>> +      -
> 
> This doesn't match the text above. This would be RGBX2101010. I'm not
> sure which format you want, so I don't know if it's the documentation or
> the format name that is incorrect. The next two formats also seem
> incorrect to me.

Right, the text should say big endian instead of little endian.

  Tomi

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Laurent Pinchart]

Hi Tomi,

On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 21:10, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>   .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
> >>   drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
> >>   include/uapi/linux/videodev2.h                |   3 +
> >>   3 files changed, 200 insertions(+)
> >>
> >> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> index 30f51cd33f99..de78cd2dcd73 100644
> >> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
> >>       \normalsize
> >>   
> >>   
> >> +10 Bits Per Component
> >> +=====================
> >> +
> >> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> >> +bytes. They are named based on the order of the RGB components as seen in a
> >> +32-bit word, which is then stored in memory in little endian byte order
> >> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
> >> +number of bits for each component.
> >> +
> >> +.. raw:: latex
> >> +
> >> +    \begingroup
> >> +    \tiny
> >> +    \setlength{\tabcolsep}{2pt}
> >> +
> >> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> >> +
> >> +
> >> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> >> +    :header-rows:  2
> >> +    :stub-columns: 0
> >> +
> >> +    * - Identifier
> >> +      - Code
> >> +      - :cspan:`7` Byte 0 in memory
> >> +      - :cspan:`7` Byte 1
> >> +      - :cspan:`7` Byte 2
> >> +      - :cspan:`7` Byte 3
> >> +    * -
> >> +      -
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +    * .. _V4L2-PIX-FMT-XBGR2101010:
> >> +
> >> +      - ``V4L2_PIX_FMT_XBGR2101010``
> >> +      - 'RX30'
> >> +
> >> +      - b\ :sub:`5`
> >> +      - b\ :sub:`4`
> >> +      - b\ :sub:`3`
> >> +      - b\ :sub:`2`
> >> +      - b\ :sub:`1`
> >> +      - b\ :sub:`0`
> >> +      - x
> >> +      - x
> >> +
> >> +      - g\ :sub:`3`
> >> +      - g\ :sub:`2`
> >> +      - g\ :sub:`1`
> >> +      - g\ :sub:`0`
> >> +      - b\ :sub:`9`
> >> +      - b\ :sub:`8`
> >> +      - b\ :sub:`7`
> >> +      - b\ :sub:`6`
> >> +
> >> +      - r\ :sub:`1`
> >> +      - r\ :sub:`0`
> >> +      - g\ :sub:`9`
> >> +      - g\ :sub:`8`
> >> +      - g\ :sub:`7`
> >> +      - g\ :sub:`6`
> >> +      - g\ :sub:`5`
> >> +      - g\ :sub:`4`
> >> +
> >> +      - r\ :sub:`9`
> >> +      - r\ :sub:`8`
> >> +      - r\ :sub:`7`
> >> +      - r\ :sub:`6`
> >> +      - r\ :sub:`5`
> >> +      - r\ :sub:`4`
> >> +      - r\ :sub:`3`
> >> +      - r\ :sub:`2`
> >> +      -
> > 
> > This doesn't match the text above. This would be RGBX2101010. I'm not
> > sure which format you want, so I don't know if it's the documentation or
> > the format name that is incorrect. The next two formats also seem
> > incorrect to me.
> 
> Right, the text should say big endian instead of little endian.

No, in big-endian format, you would have, for instance,
V4L2_PIX_FMT_XBGR2101010 defined as

	[x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]]

in memory byte order, while the format you want to define is

	[B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]]

The issue here is that 10-bpp formats don't have an integer number of
bytes per component. They are thus more similar to the 16-bit RGB
formats, where the macro named defined the order in a 16-bit word, which
was then stored in little-endian format in memory. For 24-bit and 32-bit
formats, we departed from that rule by using the byte memory order in
the macro name. For 10-bpp RGB formats we can't do so anymore. The most
sensible option is thus, I think, to use the same naming scheme as the
16-bit RGB formats, which incidentaly matches the DRM naming scheme.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Laurent Pinchart]

Hi Tomi,

On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 21:10, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>   .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
> >>   drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
> >>   include/uapi/linux/videodev2.h                |   3 +
> >>   3 files changed, 200 insertions(+)
> >>
> >> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> index 30f51cd33f99..de78cd2dcd73 100644
> >> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> >> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
> >>       \normalsize
> >>   
> >>   
> >> +10 Bits Per Component
> >> +=====================
> >> +
> >> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> >> +bytes. They are named based on the order of the RGB components as seen in a
> >> +32-bit word, which is then stored in memory in little endian byte order
> >> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
> >> +number of bits for each component.
> >> +
> >> +.. raw:: latex
> >> +
> >> +    \begingroup
> >> +    \tiny
> >> +    \setlength{\tabcolsep}{2pt}
> >> +
> >> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> >> +
> >> +
> >> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> >> +    :header-rows:  2
> >> +    :stub-columns: 0
> >> +
> >> +    * - Identifier
> >> +      - Code
> >> +      - :cspan:`7` Byte 0 in memory
> >> +      - :cspan:`7` Byte 1
> >> +      - :cspan:`7` Byte 2
> >> +      - :cspan:`7` Byte 3
> >> +    * -
> >> +      -
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +
> >> +      - 7
> >> +      - 6
> >> +      - 5
> >> +      - 4
> >> +      - 3
> >> +      - 2
> >> +      - 1
> >> +      - 0
> >> +    * .. _V4L2-PIX-FMT-XBGR2101010:
> >> +
> >> +      - ``V4L2_PIX_FMT_XBGR2101010``
> >> +      - 'RX30'
> >> +
> >> +      - b\ :sub:`5`
> >> +      - b\ :sub:`4`
> >> +      - b\ :sub:`3`
> >> +      - b\ :sub:`2`
> >> +      - b\ :sub:`1`
> >> +      - b\ :sub:`0`
> >> +      - x
> >> +      - x
> >> +
> >> +      - g\ :sub:`3`
> >> +      - g\ :sub:`2`
> >> +      - g\ :sub:`1`
> >> +      - g\ :sub:`0`
> >> +      - b\ :sub:`9`
> >> +      - b\ :sub:`8`
> >> +      - b\ :sub:`7`
> >> +      - b\ :sub:`6`
> >> +
> >> +      - r\ :sub:`1`
> >> +      - r\ :sub:`0`
> >> +      - g\ :sub:`9`
> >> +      - g\ :sub:`8`
> >> +      - g\ :sub:`7`
> >> +      - g\ :sub:`6`
> >> +      - g\ :sub:`5`
> >> +      - g\ :sub:`4`
> >> +
> >> +      - r\ :sub:`9`
> >> +      - r\ :sub:`8`
> >> +      - r\ :sub:`7`
> >> +      - r\ :sub:`6`
> >> +      - r\ :sub:`5`
> >> +      - r\ :sub:`4`
> >> +      - r\ :sub:`3`
> >> +      - r\ :sub:`2`
> >> +      -
> > 
> > This doesn't match the text above. This would be RGBX2101010. I'm not
> > sure which format you want, so I don't know if it's the documentation or
> > the format name that is incorrect. The next two formats also seem
> > incorrect to me.
> 
> Right, the text should say big endian instead of little endian.

No, in big-endian format, you would have, for instance,
V4L2_PIX_FMT_XBGR2101010 defined as

	[x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]]

in memory byte order, while the format you want to define is

	[B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]]

The issue here is that 10-bpp formats don't have an integer number of
bytes per component. They are thus more similar to the 16-bit RGB
formats, where the macro named defined the order in a 16-bit word, which
was then stored in little-endian format in memory. For 24-bit and 32-bit
formats, we departed from that rule by using the byte memory order in
the macro name. For 10-bpp RGB formats we can't do so anymore. The most
sensible option is thus, I think, to use the same naming scheme as the
16-bit RGB formats, which incidentaly matches the DRM naming scheme.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Tomi Valkeinen]

On 20/12/2022 16:24, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
>> On 19/12/2022 21:10, Laurent Pinchart wrote:
>>> On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
>>>> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>    .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>>>>    drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>>>>    include/uapi/linux/videodev2.h                |   3 +
>>>>    3 files changed, 200 insertions(+)
>>>>
>>>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> index 30f51cd33f99..de78cd2dcd73 100644
>>>> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>>>>        \normalsize
>>>>    
>>>>    
>>>> +10 Bits Per Component
>>>> +=====================
>>>> +
>>>> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
>>>> +bytes. They are named based on the order of the RGB components as seen in a
>>>> +32-bit word, which is then stored in memory in little endian byte order
>>>> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
>>>> +number of bits for each component.
>>>> +
>>>> +.. raw:: latex
>>>> +
>>>> +    \begingroup
>>>> +    \tiny
>>>> +    \setlength{\tabcolsep}{2pt}
>>>> +
>>>> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
>>>> +
>>>> +
>>>> +.. flat-table:: RGB Formats 10 Bits Per Color Component
>>>> +    :header-rows:  2
>>>> +    :stub-columns: 0
>>>> +
>>>> +    * - Identifier
>>>> +      - Code
>>>> +      - :cspan:`7` Byte 0 in memory
>>>> +      - :cspan:`7` Byte 1
>>>> +      - :cspan:`7` Byte 2
>>>> +      - :cspan:`7` Byte 3
>>>> +    * -
>>>> +      -
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +    * .. _V4L2-PIX-FMT-XBGR2101010:
>>>> +
>>>> +      - ``V4L2_PIX_FMT_XBGR2101010``
>>>> +      - 'RX30'
>>>> +
>>>> +      - b\ :sub:`5`
>>>> +      - b\ :sub:`4`
>>>> +      - b\ :sub:`3`
>>>> +      - b\ :sub:`2`
>>>> +      - b\ :sub:`1`
>>>> +      - b\ :sub:`0`
>>>> +      - x
>>>> +      - x
>>>> +
>>>> +      - g\ :sub:`3`
>>>> +      - g\ :sub:`2`
>>>> +      - g\ :sub:`1`
>>>> +      - g\ :sub:`0`
>>>> +      - b\ :sub:`9`
>>>> +      - b\ :sub:`8`
>>>> +      - b\ :sub:`7`
>>>> +      - b\ :sub:`6`
>>>> +
>>>> +      - r\ :sub:`1`
>>>> +      - r\ :sub:`0`
>>>> +      - g\ :sub:`9`
>>>> +      - g\ :sub:`8`
>>>> +      - g\ :sub:`7`
>>>> +      - g\ :sub:`6`
>>>> +      - g\ :sub:`5`
>>>> +      - g\ :sub:`4`
>>>> +
>>>> +      - r\ :sub:`9`
>>>> +      - r\ :sub:`8`
>>>> +      - r\ :sub:`7`
>>>> +      - r\ :sub:`6`
>>>> +      - r\ :sub:`5`
>>>> +      - r\ :sub:`4`
>>>> +      - r\ :sub:`3`
>>>> +      - r\ :sub:`2`
>>>> +      -
>>>
>>> This doesn't match the text above. This would be RGBX2101010. I'm not
>>> sure which format you want, so I don't know if it's the documentation or
>>> the format name that is incorrect. The next two formats also seem
>>> incorrect to me.
>>
>> Right, the text should say big endian instead of little endian.
> 
> No, in big-endian format, you would have, for instance,
> V4L2_PIX_FMT_XBGR2101010 defined as
> 
> 	[x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]]
> 
> in memory byte order, while the format you want to define is
> 
> 	[B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]]

Yes, I see your point.

> The issue here is that 10-bpp formats don't have an integer number of
> bytes per component. They are thus more similar to the 16-bit RGB
> formats, where the macro named defined the order in a 16-bit word, which
> was then stored in little-endian format in memory. For 24-bit and 32-bit
> formats, we departed from that rule by using the byte memory order in
> the macro name. For 10-bpp RGB formats we can't do so anymore. The most
> sensible option is thus, I think, to use the same naming scheme as the
> 16-bit RGB formats, which incidentaly matches the DRM naming scheme.

I agree. It wasn't quite clear to me if Hans agreed to that in the patch 
7 discussions, but as you say, maybe that's the only option that makes 
sense.

  Tomi

Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

[Tomi Valkeinen]

On 20/12/2022 16:24, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
>> On 19/12/2022 21:10, Laurent Pinchart wrote:
>>> On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
>>>> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>> ---
>>>>    .../userspace-api/media/v4l/pixfmt-rgb.rst    | 194 ++++++++++++++++++
>>>>    drivers/media/v4l2-core/v4l2-ioctl.c          |   3 +
>>>>    include/uapi/linux/videodev2.h                |   3 +
>>>>    3 files changed, 200 insertions(+)
>>>>
>>>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> index 30f51cd33f99..de78cd2dcd73 100644
>>>> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
>>>> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or
>>>>        \normalsize
>>>>    
>>>>    
>>>> +10 Bits Per Component
>>>> +=====================
>>>> +
>>>> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
>>>> +bytes. They are named based on the order of the RGB components as seen in a
>>>> +32-bit word, which is then stored in memory in little endian byte order
>>>> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the
>>>> +number of bits for each component.
>>>> +
>>>> +.. raw:: latex
>>>> +
>>>> +    \begingroup
>>>> +    \tiny
>>>> +    \setlength{\tabcolsep}{2pt}
>>>> +
>>>> +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
>>>> +
>>>> +
>>>> +.. flat-table:: RGB Formats 10 Bits Per Color Component
>>>> +    :header-rows:  2
>>>> +    :stub-columns: 0
>>>> +
>>>> +    * - Identifier
>>>> +      - Code
>>>> +      - :cspan:`7` Byte 0 in memory
>>>> +      - :cspan:`7` Byte 1
>>>> +      - :cspan:`7` Byte 2
>>>> +      - :cspan:`7` Byte 3
>>>> +    * -
>>>> +      -
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +
>>>> +      - 7
>>>> +      - 6
>>>> +      - 5
>>>> +      - 4
>>>> +      - 3
>>>> +      - 2
>>>> +      - 1
>>>> +      - 0
>>>> +    * .. _V4L2-PIX-FMT-XBGR2101010:
>>>> +
>>>> +      - ``V4L2_PIX_FMT_XBGR2101010``
>>>> +      - 'RX30'
>>>> +
>>>> +      - b\ :sub:`5`
>>>> +      - b\ :sub:`4`
>>>> +      - b\ :sub:`3`
>>>> +      - b\ :sub:`2`
>>>> +      - b\ :sub:`1`
>>>> +      - b\ :sub:`0`
>>>> +      - x
>>>> +      - x
>>>> +
>>>> +      - g\ :sub:`3`
>>>> +      - g\ :sub:`2`
>>>> +      - g\ :sub:`1`
>>>> +      - g\ :sub:`0`
>>>> +      - b\ :sub:`9`
>>>> +      - b\ :sub:`8`
>>>> +      - b\ :sub:`7`
>>>> +      - b\ :sub:`6`
>>>> +
>>>> +      - r\ :sub:`1`
>>>> +      - r\ :sub:`0`
>>>> +      - g\ :sub:`9`
>>>> +      - g\ :sub:`8`
>>>> +      - g\ :sub:`7`
>>>> +      - g\ :sub:`6`
>>>> +      - g\ :sub:`5`
>>>> +      - g\ :sub:`4`
>>>> +
>>>> +      - r\ :sub:`9`
>>>> +      - r\ :sub:`8`
>>>> +      - r\ :sub:`7`
>>>> +      - r\ :sub:`6`
>>>> +      - r\ :sub:`5`
>>>> +      - r\ :sub:`4`
>>>> +      - r\ :sub:`3`
>>>> +      - r\ :sub:`2`
>>>> +      -
>>>
>>> This doesn't match the text above. This would be RGBX2101010. I'm not
>>> sure which format you want, so I don't know if it's the documentation or
>>> the format name that is incorrect. The next two formats also seem
>>> incorrect to me.
>>
>> Right, the text should say big endian instead of little endian.
> 
> No, in big-endian format, you would have, for instance,
> V4L2_PIX_FMT_XBGR2101010 defined as
> 
> 	[x, x, B[9:4]], [B[3:0], G[9:6]], [G[5:0], R[1:0]], [R[7:0]]
> 
> in memory byte order, while the format you want to define is
> 
> 	[B[5:0], x, x], [G[3:0], B[9:6]], [R[1:0], G[9:4]], [R[9:2]]

Yes, I see your point.

> The issue here is that 10-bpp formats don't have an integer number of
> bytes per component. They are thus more similar to the 16-bit RGB
> formats, where the macro named defined the order in a 16-bit word, which
> was then stored in little-endian format in memory. For 24-bit and 32-bit
> formats, we departed from that rule by using the byte memory order in
> the macro name. For 10-bpp RGB formats we can't do so anymore. The most
> sensible option is thus, I think, to use the same naming scheme as the
> 16-bit RGB formats, which incidentaly matches the DRM naming scheme.

I agree. It wasn't quite clear to me if Hans agreed to that in the patch 
7 discussions, but as you say, maybe that's the only option that makes 
sense.

  Tomi

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Tomi Valkeinen]

On 19/12/2022 23:01, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
>> V3U is actually gen4, not gen3. The same IP is also used in the
>> (not-yet-supported) V4H.
>>
>> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
>> to represent the model correctly. V3U and V4H can still be
>> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
>>
>> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
>> and update the code to correcly match for gen 4.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>   drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
>>   drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
>>   drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
>>   drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
>>   7 files changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> index c260d318d298..5710152d6511 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
>>   		.wpf_count = 2,
>>   		.num_bru_inputs = 5,
>>   	}, {
>> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
>> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
>>   		.model = "VSP2-D",
>> -		.gen = 3,
>> +		.gen = 4,
>>   		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
>>   		.lif_count = 1,
>>   		.rpf_count = 5,
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> index bf3f981f93a1..e6492deb0a64 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
>>   
>>   	/* Initialize the control handler. */
>>   	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
>> -			       vsp1->info->gen == 3 ? 2 : 1);
>> +			       vsp1->info->gen >= 3 ? 2 : 1);
>>   	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>>   						  &hgo_max_rgb_control, NULL);
>> -	if (vsp1->info->gen == 3)
>> +	if (vsp1->info->gen >= 3)
>>   		hgo->ctrls.num_bins =
>>   			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>>   					     &hgo_num_bins_control, NULL);
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> index 186a5730e1e3..0ab2e0c70474 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
>>   		break;
>>   
>>   	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
>> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:
> 
> While this doesn't cause any functional change, it doesn't fall into the
> renaming explained in the commit message. I'd make a mention of it
> there.

The message says "update the code to correcly match for gen 4". (I see a 
typo there =)). Doesn't that cover this change? It's similar to the if() 
changes, where we now check for >= 3.

  Tomi

> Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
>>   	default:
>>   		hbth = 0;
>>   		obth = 3000;
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> index 8928f4c6bb55..8c9333f76858 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> @@ -766,7 +766,7 @@
>>   #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
>>   #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
>>   #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
>> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
>> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
>>   /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
>>   #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> index 75083cb234fe..045aa54f7998 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>>   	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>>   	 * otherwise.
>>   	 *
>> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
>> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
>>   	 * alpha channel by a fixed global alpha value, and multiply the pixel
>>   	 * components to convert the input to premultiplied alpha.
>>   	 *
>>   	 * As alpha premultiplication is available in the BRx for both Gen2 and
>> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
>> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
>>   	 * alpha multiplication only. This however prevents conversion to
>>   	 * premultiplied alpha if no BRx is present in the pipeline. If that use
>>   	 * case turns out to be useful we will revisit the implementation (for
>>   	 * Gen3 only).
>>   	 *
>> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
>> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
>>   	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
>>   	 * contains an alpha channel. On Gen2 the global alpha is ignored in
>>   	 * that case.
>> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>>   		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
>>   				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
>>   
>> -	if (entity->vsp1->info->gen == 3) {
>> +	if (entity->vsp1->info->gen >= 3) {
>>   		u32 mult;
>>   
>>   		if (fmtinfo->alpha) {
>> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
>>   	}
>>   
>>   	/*
>> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
>> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>>   	 * formats. Swap the U and V planes manually in that case.
>>   	 */
>> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
>> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>>   	    fmtinfo->swap_uv)
>>   		swap(mem.addr[1], mem.addr[2]);
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> index 9d24647c8f32..544012fd1fe9 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
>>   	div_size = format->width;
>>   
>>   	/*
>> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
>> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
>>   	 * with a single partition that covers the whole output.
>>   	 */
>> -	if (vsp1->info->gen == 3) {
>> +	if (vsp1->info->gen >= 3) {
>>   		list_for_each_entry(entity, &pipe->entities, list_pipe) {
>>   			unsigned int entity_max;
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> index 94e91d7bb56c..d0074ca00920 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
>>   	}
>>   
>>   	/*
>> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
>> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>>   	 * formats. Swap the U and V planes manually in that case.
>>   	 */
>> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
>> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>>   	    fmtinfo->swap_uv)
>>   		swap(mem.addr[1], mem.addr[2]);
>>   
> 

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Tomi Valkeinen]

On 19/12/2022 23:01, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
>> V3U is actually gen4, not gen3. The same IP is also used in the
>> (not-yet-supported) V4H.
>>
>> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
>> to represent the model correctly. V3U and V4H can still be
>> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
>>
>> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
>> and update the code to correcly match for gen 4.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> ---
>>   drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
>>   drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
>>   drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
>>   drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
>>   drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
>>   7 files changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> index c260d318d298..5710152d6511 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
>> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
>>   		.wpf_count = 2,
>>   		.num_bru_inputs = 5,
>>   	}, {
>> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
>> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
>>   		.model = "VSP2-D",
>> -		.gen = 3,
>> +		.gen = 4,
>>   		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
>>   		.lif_count = 1,
>>   		.rpf_count = 5,
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> index bf3f981f93a1..e6492deb0a64 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
>> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
>>   
>>   	/* Initialize the control handler. */
>>   	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
>> -			       vsp1->info->gen == 3 ? 2 : 1);
>> +			       vsp1->info->gen >= 3 ? 2 : 1);
>>   	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>>   						  &hgo_max_rgb_control, NULL);
>> -	if (vsp1->info->gen == 3)
>> +	if (vsp1->info->gen >= 3)
>>   		hgo->ctrls.num_bins =
>>   			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>>   					     &hgo_num_bins_control, NULL);
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> index 186a5730e1e3..0ab2e0c70474 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
>> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
>>   		break;
>>   
>>   	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
>> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:
> 
> While this doesn't cause any functional change, it doesn't fall into the
> renaming explained in the commit message. I'd make a mention of it
> there.

The message says "update the code to correcly match for gen 4". (I see a 
typo there =)). Doesn't that cover this change? It's similar to the if() 
changes, where we now check for >= 3.

  Tomi

> Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
>>   	default:
>>   		hbth = 0;
>>   		obth = 3000;
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> index 8928f4c6bb55..8c9333f76858 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
>> @@ -766,7 +766,7 @@
>>   #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
>>   #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
>>   #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
>> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
>> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
>>   /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
>>   #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> index 75083cb234fe..045aa54f7998 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
>> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>>   	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>>   	 * otherwise.
>>   	 *
>> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
>> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
>>   	 * alpha channel by a fixed global alpha value, and multiply the pixel
>>   	 * components to convert the input to premultiplied alpha.
>>   	 *
>>   	 * As alpha premultiplication is available in the BRx for both Gen2 and
>> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
>> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
>>   	 * alpha multiplication only. This however prevents conversion to
>>   	 * premultiplied alpha if no BRx is present in the pipeline. If that use
>>   	 * case turns out to be useful we will revisit the implementation (for
>>   	 * Gen3 only).
>>   	 *
>> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
>> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
>>   	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
>>   	 * contains an alpha channel. On Gen2 the global alpha is ignored in
>>   	 * that case.
>> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
>>   		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
>>   				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
>>   
>> -	if (entity->vsp1->info->gen == 3) {
>> +	if (entity->vsp1->info->gen >= 3) {
>>   		u32 mult;
>>   
>>   		if (fmtinfo->alpha) {
>> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
>>   	}
>>   
>>   	/*
>> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
>> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>>   	 * formats. Swap the U and V planes manually in that case.
>>   	 */
>> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
>> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>>   	    fmtinfo->swap_uv)
>>   		swap(mem.addr[1], mem.addr[2]);
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> index 9d24647c8f32..544012fd1fe9 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
>> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
>>   	div_size = format->width;
>>   
>>   	/*
>> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
>> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
>>   	 * with a single partition that covers the whole output.
>>   	 */
>> -	if (vsp1->info->gen == 3) {
>> +	if (vsp1->info->gen >= 3) {
>>   		list_for_each_entry(entity, &pipe->entities, list_pipe) {
>>   			unsigned int entity_max;
>>   
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> index 94e91d7bb56c..d0074ca00920 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
>> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
>>   	}
>>   
>>   	/*
>> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
>> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
>>   	 * formats. Swap the U and V planes manually in that case.
>>   	 */
>> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
>> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
>>   	    fmtinfo->swap_uv)
>>   		swap(mem.addr[1], mem.addr[2]);
>>   
> 

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Laurent Pinchart]

Hi Tomi,

On Wed, Dec 21, 2022 at 09:48:10AM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 23:01, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> >> V3U is actually gen4, not gen3. The same IP is also used in the
> >> (not-yet-supported) V4H.
> >>
> >> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> >> to represent the model correctly. V3U and V4H can still be
> >> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
> >>
> >> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> >> and update the code to correcly match for gen 4.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>   drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
> >>   drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
> >>   drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
> >>   drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
> >>   7 files changed, 16 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> index c260d318d298..5710152d6511 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
> >>   		.wpf_count = 2,
> >>   		.num_bru_inputs = 5,
> >>   	}, {
> >> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> >> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
> >>   		.model = "VSP2-D",
> >> -		.gen = 3,
> >> +		.gen = 4,
> >>   		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
> >>   		.lif_count = 1,
> >>   		.rpf_count = 5,
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> index bf3f981f93a1..e6492deb0a64 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
> >>   
> >>   	/* Initialize the control handler. */
> >>   	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
> >> -			       vsp1->info->gen == 3 ? 2 : 1);
> >> +			       vsp1->info->gen >= 3 ? 2 : 1);
> >>   	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
> >>   						  &hgo_max_rgb_control, NULL);
> >> -	if (vsp1->info->gen == 3)
> >> +	if (vsp1->info->gen >= 3)
> >>   		hgo->ctrls.num_bins =
> >>   			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
> >>   					     &hgo_num_bins_control, NULL);
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> index 186a5730e1e3..0ab2e0c70474 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
> >>   		break;
> >>   
> >>   	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> >> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:
> > 
> > While this doesn't cause any functional change, it doesn't fall into the
> > renaming explained in the commit message. I'd make a mention of it
> > there.
> 
> The message says "update the code to correcly match for gen 4". (I see a 
> typo there =)). Doesn't that cover this change? It's similar to the if() 
> changes, where we now check for >= 3.

Possibly :-) This code change isn't needed as the default cases handles
gen4. It's still desirable though.

No need to send a new version for this.

> > Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > 
> >>   	default:
> >>   		hbth = 0;
> >>   		obth = 3000;
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> index 8928f4c6bb55..8c9333f76858 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> @@ -766,7 +766,7 @@
> >>   #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
> >>   #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
> >>   #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
> >> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
> >> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
> >>   /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
> >>   #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> index 75083cb234fe..045aa54f7998 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
> >>   	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
> >>   	 * otherwise.
> >>   	 *
> >> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
> >> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
> >>   	 * alpha channel by a fixed global alpha value, and multiply the pixel
> >>   	 * components to convert the input to premultiplied alpha.
> >>   	 *
> >>   	 * As alpha premultiplication is available in the BRx for both Gen2 and
> >> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
> >> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
> >>   	 * alpha multiplication only. This however prevents conversion to
> >>   	 * premultiplied alpha if no BRx is present in the pipeline. If that use
> >>   	 * case turns out to be useful we will revisit the implementation (for
> >>   	 * Gen3 only).
> >>   	 *
> >> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
> >> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
> >>   	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
> >>   	 * contains an alpha channel. On Gen2 the global alpha is ignored in
> >>   	 * that case.
> >> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
> >>   		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
> >>   				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
> >>   
> >> -	if (entity->vsp1->info->gen == 3) {
> >> +	if (entity->vsp1->info->gen >= 3) {
> >>   		u32 mult;
> >>   
> >>   		if (fmtinfo->alpha) {
> >> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> >>   	}
> >>   
> >>   	/*
> >> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> >> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
> >>   	 * formats. Swap the U and V planes manually in that case.
> >>   	 */
> >> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> >> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
> >>   	    fmtinfo->swap_uv)
> >>   		swap(mem.addr[1], mem.addr[2]);
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> index 9d24647c8f32..544012fd1fe9 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
> >>   	div_size = format->width;
> >>   
> >>   	/*
> >> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
> >> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
> >>   	 * with a single partition that covers the whole output.
> >>   	 */
> >> -	if (vsp1->info->gen == 3) {
> >> +	if (vsp1->info->gen >= 3) {
> >>   		list_for_each_entry(entity, &pipe->entities, list_pipe) {
> >>   			unsigned int entity_max;
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> index 94e91d7bb56c..d0074ca00920 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
> >>   	}
> >>   
> >>   	/*
> >> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> >> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
> >>   	 * formats. Swap the U and V planes manually in that case.
> >>   	 */
> >> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> >> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
> >>   	    fmtinfo->swap_uv)
> >>   		swap(mem.addr[1], mem.addr[2]);
> >>   

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

[Laurent Pinchart]

Hi Tomi,

On Wed, Dec 21, 2022 at 09:48:10AM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 23:01, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> >> V3U is actually gen4, not gen3. The same IP is also used in the
> >> (not-yet-supported) V4H.
> >>
> >> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> >> to represent the model correctly. V3U and V4H can still be
> >> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
> >>
> >> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> >> and update the code to correcly match for gen 4.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >>   drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
> >>   drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
> >>   drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++++++------
> >>   drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
> >>   drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
> >>   7 files changed, 16 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> index c260d318d298..5710152d6511 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> >> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
> >>   		.wpf_count = 2,
> >>   		.num_bru_inputs = 5,
> >>   	}, {
> >> -		.version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> >> +		.version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
> >>   		.model = "VSP2-D",
> >> -		.gen = 3,
> >> +		.gen = 4,
> >>   		.features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
> >>   		.lif_count = 1,
> >>   		.rpf_count = 5,
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> index bf3f981f93a1..e6492deb0a64 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> >> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
> >>   
> >>   	/* Initialize the control handler. */
> >>   	v4l2_ctrl_handler_init(&hgo->ctrls.handler,
> >> -			       vsp1->info->gen == 3 ? 2 : 1);
> >> +			       vsp1->info->gen >= 3 ? 2 : 1);
> >>   	hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
> >>   						  &hgo_max_rgb_control, NULL);
> >> -	if (vsp1->info->gen == 3)
> >> +	if (vsp1->info->gen >= 3)
> >>   		hgo->ctrls.num_bins =
> >>   			v4l2_ctrl_new_custom(&hgo->ctrls.handler,
> >>   					     &hgo_num_bins_control, NULL);
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> index 186a5730e1e3..0ab2e0c70474 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> >> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity,
> >>   		break;
> >>   
> >>   	case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> >> +	case VI6_IP_VERSION_MODEL_VSPD_GEN4:
> > 
> > While this doesn't cause any functional change, it doesn't fall into the
> > renaming explained in the commit message. I'd make a mention of it
> > there.
> 
> The message says "update the code to correcly match for gen 4". (I see a 
> typo there =)). Doesn't that cover this change? It's similar to the if() 
> changes, where we now check for >= 3.

Possibly :-) This code change isn't needed as the default cases handles
gen4. It's still desirable though.

No need to send a new version for this.

> > Conditional-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > 
> >>   	default:
> >>   		hbth = 0;
> >>   		obth = 3000;
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> index 8928f4c6bb55..8c9333f76858 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> >> @@ -766,7 +766,7 @@
> >>   #define VI6_IP_VERSION_MODEL_VSPD_V3	(0x18 << 8)
> >>   #define VI6_IP_VERSION_MODEL_VSPDL_GEN3	(0x19 << 8)
> >>   #define VI6_IP_VERSION_MODEL_VSPBS_GEN3	(0x1a << 8)
> >> -#define VI6_IP_VERSION_MODEL_VSPD_V3U	(0x1c << 8)
> >> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4	(0x1c << 8)
> >>   /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
> >>   #define VI6_IP_VERSION_MODEL_VSPD_RZG2L	(0x80 << 8)
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> index 75083cb234fe..045aa54f7998 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> >> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
> >>   	 * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
> >>   	 * otherwise.
> >>   	 *
> >> -	 * The Gen3 RPF has extended alpha capability and can both multiply the
> >> +	 * The Gen3+ RPF has extended alpha capability and can both multiply the
> >>   	 * alpha channel by a fixed global alpha value, and multiply the pixel
> >>   	 * components to convert the input to premultiplied alpha.
> >>   	 *
> >>   	 * As alpha premultiplication is available in the BRx for both Gen2 and
> >> -	 * Gen3 we handle it there and use the Gen3 alpha multiplier for global
> >> +	 * Gen3+ we handle it there and use the Gen3 alpha multiplier for global
> >>   	 * alpha multiplication only. This however prevents conversion to
> >>   	 * premultiplied alpha if no BRx is present in the pipeline. If that use
> >>   	 * case turns out to be useful we will revisit the implementation (for
> >>   	 * Gen3 only).
> >>   	 *
> >> -	 * We enable alpha multiplication on Gen3 using the fixed alpha value
> >> +	 * We enable alpha multiplication on Gen3+ using the fixed alpha value
> >>   	 * set through the V4L2_CID_ALPHA_COMPONENT control when the input
> >>   	 * contains an alpha channel. On Gen2 the global alpha is ignored in
> >>   	 * that case.
> >> @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
> >>   		       (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
> >>   				       : VI6_RPF_ALPH_SEL_ASEL_FIXED));
> >>   
> >> -	if (entity->vsp1->info->gen == 3) {
> >> +	if (entity->vsp1->info->gen >= 3) {
> >>   		u32 mult;
> >>   
> >>   		if (fmtinfo->alpha) {
> >> @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> >>   	}
> >>   
> >>   	/*
> >> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> >> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
> >>   	 * formats. Swap the U and V planes manually in that case.
> >>   	 */
> >> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> >> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
> >>   	    fmtinfo->swap_uv)
> >>   		swap(mem.addr[1], mem.addr[2]);
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> index 9d24647c8f32..544012fd1fe9 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >> @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe)
> >>   	div_size = format->width;
> >>   
> >>   	/*
> >> -	 * Only Gen3 hardware requires image partitioning, Gen2 will operate
> >> +	 * Only Gen3+ hardware requires image partitioning, Gen2 will operate
> >>   	 * with a single partition that covers the whole output.
> >>   	 */
> >> -	if (vsp1->info->gen == 3) {
> >> +	if (vsp1->info->gen >= 3) {
> >>   		list_for_each_entry(entity, &pipe->entities, list_pipe) {
> >>   			unsigned int entity_max;
> >>   
> >> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> index 94e91d7bb56c..d0074ca00920 100644
> >> --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c
> >> @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity,
> >>   	}
> >>   
> >>   	/*
> >> -	 * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> >> +	 * On Gen3+ hardware the SPUVS bit has no effect on 3-planar
> >>   	 * formats. Swap the U and V planes manually in that case.
> >>   	 */
> >> -	if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> >> +	if (vsp1->info->gen >= 3 && format->num_planes == 3 &&
> >>   	    fmtinfo->swap_uv)
> >>   		swap(mem.addr[1], mem.addr[2]);
> >>   

-- 
Regards,

Laurent Pinchart