[PATCH 0/2] Introduce HDMI Video Guard Band test pattern

[PATCH 0/2] Introduce HDMI Video Guard Band test pattern

[Hans Verkuil]

These patches add support for a specific test pattern to test HDMI
receivers.

Four pixels of the RGB color 0xab55ab are inserted at the left hand side of
the image. This is only done for 3 or 4 byte RGB pixel formats. The HDMI
TMDS encoding of this pixel value equals the Video Guard Band value as
defined by HDMI (see section 5.2.2.1 in the HDMI 1.3 Specification) that
preceeds the first actual pixel of a video line. If an HDMI receiver
doesn't handle this correctly, then it might keep skipping these Video
Guard Band patterns and end up with a shorter video line. So this is a
nice pattern to test with.

And yes, this does cause one receiver we tested with to lose sync :-)

Regards,

	Hans

Hans Verkuil (2):
  media: v4l2-tpg: add HDMI Video Guard Band test pattern
  media: vivid: add HDMI Video Guard Band control

 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 38 +++++++++++++++++++
 .../media/test-drivers/vivid/vivid-ctrls.c    | 14 +++++++
 include/media/tpg/v4l2-tpg.h                  | 16 ++++++++
 3 files changed, 68 insertions(+)

-- 
2.34.1

[PATCH 1/2] media: v4l2-tpg: add HDMI Video Guard Band test pattern

[Hans Verkuil]

This inserts 4 pixels of the RGB color 0xab55ab at the left hand side of
the image. This is only done for 3 or 4 byte RGB pixel formats. The HDMI
TMDS encoding of this pixel value equals the Video Guard Band value as
defined by HDMI (see section 5.2.2.1 in the HDMI 1.3 Specification) that
preceeds the first actual pixel of a video line. If an HDMI receiver
doesn't handle this correctly, then it might keep skipping these Video
Guard Band patterns and end up with a shorter video line. So this is a
nice pattern to test with.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 38 +++++++++++++++++++
 include/media/tpg/v4l2-tpg.h                  | 16 ++++++++
 2 files changed, 54 insertions(+)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 7607b516a7c4..a67e1b6ea296 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -2402,6 +2402,44 @@ static void tpg_fill_plane_extras(const struct tpg_data *tpg,
 			((params->sav_eav_f ^ vact) << 1) |
 			(hact ^ vact ^ params->sav_eav_f);
 	}
+	if (tpg->insert_hdmi_video_guard_band) {
+		unsigned i;
+
+		switch (tpg->fourcc) {
+		case V4L2_PIX_FMT_BGR24:
+		case V4L2_PIX_FMT_RGB24:
+			for (i = 0; i < 3 * 4; i += 3) {
+				vbuf[i] = 0xab;
+				vbuf[i + 1] = 0x55;
+				vbuf[i + 2] = 0xab;
+			}
+			break;
+		case V4L2_PIX_FMT_RGB32:
+		case V4L2_PIX_FMT_ARGB32:
+		case V4L2_PIX_FMT_XRGB32:
+		case V4L2_PIX_FMT_BGRX32:
+		case V4L2_PIX_FMT_BGRA32:
+			for (i = 0; i < 4 * 4; i += 4) {
+				vbuf[i] = 0x00;
+				vbuf[i + 1] = 0xab;
+				vbuf[i + 2] = 0x55;
+				vbuf[i + 3] = 0xab;
+			}
+			break;
+		case V4L2_PIX_FMT_BGR32:
+		case V4L2_PIX_FMT_XBGR32:
+		case V4L2_PIX_FMT_ABGR32:
+		case V4L2_PIX_FMT_RGBX32:
+		case V4L2_PIX_FMT_RGBA32:
+			for (i = 0; i < 4 * 4; i += 4) {
+				vbuf[i] = 0xab;
+				vbuf[i + 1] = 0x55;
+				vbuf[i + 2] = 0xab;
+				vbuf[i + 3] = 0x00;
+			}
+			break;
+		}
+	}
 }
 
 static void tpg_fill_plane_pattern(const struct tpg_data *tpg,
diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
index 181dcbe777f3..a55088921d1d 100644
--- a/include/media/tpg/v4l2-tpg.h
+++ b/include/media/tpg/v4l2-tpg.h
@@ -210,6 +210,7 @@ struct tpg_data {
 	bool				show_square;
 	bool				insert_sav;
 	bool				insert_eav;
+	bool				insert_hdmi_video_guard_band;
 
 	/* Test pattern movement */
 	enum tpg_move_mode		mv_hor_mode;
@@ -591,6 +592,21 @@ static inline void tpg_s_insert_eav(struct tpg_data *tpg, bool insert_eav)
 	tpg->insert_eav = insert_eav;
 }
 
+/*
+ * This inserts 4 pixels of the RGB color 0xab55ab at the left hand side of the
+ * image. This is only done for 3 or 4 byte RGB pixel formats. This pixel value
+ * equals the Video Guard Band value as defined by HDMI (see section 5.2.2.1
+ * in the HDMI 1.3 Specification) that preceeds the first actual pixel. If the
+ * HDMI receiver doesn't handle this correctly, then it might keep skipping
+ * these Video Guard Band patterns and end up with a shorter video line. So this
+ * is a nice pattern to test with.
+ */
+static inline void tpg_s_insert_hdmi_video_guard_band(struct tpg_data *tpg,
+						      bool insert_hdmi_video_guard_band)
+{
+	tpg->insert_hdmi_video_guard_band = insert_hdmi_video_guard_band;
+}
+
 void tpg_update_mv_step(struct tpg_data *tpg);
 
 static inline void tpg_s_mv_hor_mode(struct tpg_data *tpg,
-- 
2.34.1

[PATCH 2/2] media: vivid: add HDMI Video Guard Band control

[Hans Verkuil]

Add a vivid control to insert the HDMI Video Guard Band in the
image.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
---
 drivers/media/test-drivers/vivid/vivid-ctrls.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/test-drivers/vivid/vivid-ctrls.c b/drivers/media/test-drivers/vivid/vivid-ctrls.c
index e7516dc1227b..7ff8fdfda28e 100644
--- a/drivers/media/test-drivers/vivid/vivid-ctrls.c
+++ b/drivers/media/test-drivers/vivid/vivid-ctrls.c
@@ -46,6 +46,7 @@
 #define VIVID_CID_INSERT_SAV		(VIVID_CID_VIVID_BASE + 6)
 #define VIVID_CID_INSERT_EAV		(VIVID_CID_VIVID_BASE + 7)
 #define VIVID_CID_VBI_CAP_INTERLACED	(VIVID_CID_VIVID_BASE + 8)
+#define VIVID_CID_INSERT_HDMI_VIDEO_GUARD_BAND (VIVID_CID_VIVID_BASE + 9)
 
 #define VIVID_CID_HFLIP			(VIVID_CID_VIVID_BASE + 20)
 #define VIVID_CID_VFLIP			(VIVID_CID_VIVID_BASE + 21)
@@ -474,6 +475,9 @@ static int vivid_vid_cap_s_ctrl(struct v4l2_ctrl *ctrl)
 	case VIVID_CID_INSERT_EAV:
 		tpg_s_insert_eav(&dev->tpg, ctrl->val);
 		break;
+	case VIVID_CID_INSERT_HDMI_VIDEO_GUARD_BAND:
+		tpg_s_insert_hdmi_video_guard_band(&dev->tpg, ctrl->val);
+		break;
 	case VIVID_CID_HFLIP:
 		dev->sensor_hflip = ctrl->val;
 		tpg_s_hflip(&dev->tpg, dev->sensor_hflip ^ dev->hflip);
@@ -660,6 +664,15 @@ static const struct v4l2_ctrl_config vivid_ctrl_insert_eav = {
 	.step = 1,
 };
 
+static const struct v4l2_ctrl_config vivid_ctrl_insert_hdmi_video_guard_band = {
+	.ops = &vivid_vid_cap_ctrl_ops,
+	.id = VIVID_CID_INSERT_HDMI_VIDEO_GUARD_BAND,
+	.name = "Insert Video Guard Band",
+	.type = V4L2_CTRL_TYPE_BOOLEAN,
+	.max = 1,
+	.step = 1,
+};
+
 static const struct v4l2_ctrl_config vivid_ctrl_hflip = {
 	.ops = &vivid_vid_cap_ctrl_ops,
 	.id = VIVID_CID_HFLIP,
@@ -1638,6 +1651,7 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap,
 		v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_vflip, NULL);
 		v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_insert_sav, NULL);
 		v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_insert_eav, NULL);
+		v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_insert_hdmi_video_guard_band, NULL);
 		v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_reduced_fps, NULL);
 		if (show_ccs_cap) {
 			dev->ctrl_has_crop_cap = v4l2_ctrl_new_custom(hdl_vid_cap,
-- 
2.34.1

[PATCH 3/2] media: vivid.rst: document HDMI Video Guard Band control

[Hans Verkuil]

Document this new vivid test control.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
---
diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst
index 6d7175f96f74..41b2f668134e 100644
--- a/Documentation/admin-guide/media/vivid.rst
+++ b/Documentation/admin-guide/media/vivid.rst
@@ -714,6 +714,20 @@ The Test Pattern Controls are all specific to video capture.

 	does the same for the EAV (End of Active Video) code.

+- Insert Video Guard Band
+
+	adds 4 columns of pixels with the HDMI Video Guard Band code at the
+	left hand side of the image. This only works with 3 or 4 byte RGB pixel
+	formats. The RGB pixel value 0xab/0x55/0xab turns out to be equivalent
+	to the HDMI Video Guard Band code that precedes each active video line
+	(see section 5.2.2.1 in the HDMI 1.3 Specification). To test if a video
+	receiver has correct HDMI Video Guard Band processing, enable this
+	control and then move the image to the left hand side of the screen.
+	That will result in video lines that start with multiple pixels that
+	have the same value as the Video Guard Band that precedes them.
+	Receivers that will just keep skipping Video Guard Band values will
+	now fail and either loose sync or these video lines will shift.
+

 Capture Feature Selection Controls
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^