Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: dri-devel@lists.freedesktop.org
Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v3 11/13] drm/edid: add HF-EEODB support to EDID read and allocation
Date: Wed, 22 Jun 2022 13:59:25 +0300	[thread overview]
Message-ID: <d35ece8746bf31d2f54ecd540fe57db18764d5ae.1655895388.git.jani.nikula@intel.com> (raw)
In-Reply-To: <cover.1655895388.git.jani.nikula@intel.com>

HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.

Hard-coding the EEODB parsing instead of using the iterators we have is
a bit of a bummer, but we have to be able to do this on a partially
allocated EDID while reading it.

v2:
- Check for CEA Data Block Collection size (Ville)
- Amend commit message and comment about hard-coded parsing

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/drm_edid.c | 89 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 86 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a80ea0aa7b32..fa3a3e294560 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1581,6 +1581,15 @@ static bool version_greater(const struct drm_edid *drm_edid,
 		(edid->version == version && edid->revision > revision);
 }
 
+static int edid_hfeeodb_extension_block_count(const struct edid *edid);
+
+static int edid_hfeeodb_block_count(const struct edid *edid)
+{
+	int eeodb = edid_hfeeodb_extension_block_count(edid);
+
+	return eeodb ? eeodb + 1 : 0;
+}
+
 static int edid_extension_block_count(const struct edid *edid)
 {
 	return edid->extensions;
@@ -2026,6 +2035,11 @@ static struct edid *edid_filter_invalid_blocks(struct edid *edid,
 	struct edid *new;
 	int i, valid_blocks = 0;
 
+	/*
+	 * Note: If the EDID uses HF-EEODB, but has invalid blocks, we'll revert
+	 * back to regular extension count here. We don't want to start
+	 * modifying the HF-EEODB extension too.
+	 */
 	for (i = 0; i < edid_block_count(edid); i++) {
 		const void *src_block = edid_block_data(edid, i);
 
@@ -2261,7 +2275,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector *connector,
 				     size_t *size)
 {
 	enum edid_block_status status;
-	int i, invalid_blocks = 0;
+	int i, num_blocks, invalid_blocks = 0;
 	struct edid *edid, *new;
 	size_t alloc_size = EDID_LENGTH;
 
@@ -2303,7 +2317,8 @@ static struct edid *_drm_do_get_edid(struct drm_connector *connector,
 		goto fail;
 	edid = new;
 
-	for (i = 1; i < edid_block_count(edid); i++) {
+	num_blocks = edid_block_count(edid);
+	for (i = 1; i < num_blocks; i++) {
 		void *block = (void *)edid_block_data(edid, i);
 
 		status = edid_block_read(block, i, read_block, context);
@@ -2314,11 +2329,31 @@ static struct edid *_drm_do_get_edid(struct drm_connector *connector,
 			if (status == EDID_BLOCK_READ_FAIL)
 				goto fail;
 			invalid_blocks++;
+		} else if (i == 1) {
+			/*
+			 * If the first EDID extension is a CTA extension, and
+			 * the first Data Block is HF-EEODB, override the
+			 * extension block count.
+			 *
+			 * Note: HF-EEODB could specify a smaller extension
+			 * count too, but we can't risk allocating a smaller
+			 * amount.
+			 */
+			int eeodb = edid_hfeeodb_block_count(edid);
+
+			if (eeodb > num_blocks) {
+				num_blocks = eeodb;
+				alloc_size = edid_size_by_blocks(num_blocks);
+				new = krealloc(edid, alloc_size, GFP_KERNEL);
+				if (!new)
+					goto fail;
+				edid = new;
+			}
 		}
 	}
 
 	if (invalid_blocks) {
-		connector_bad_edid(connector, edid, edid_block_count(edid));
+		connector_bad_edid(connector, edid, num_blocks);
 
 		edid = edid_filter_invalid_blocks(edid, &alloc_size);
 	}
@@ -3851,6 +3886,7 @@ static int add_detailed_modes(struct drm_connector *connector,
 #define CTA_EXT_DB_HDR_STATIC_METADATA	6
 #define CTA_EXT_DB_420_VIDEO_DATA	14
 #define CTA_EXT_DB_420_VIDEO_CAP_MAP	15
+#define CTA_EXT_DB_HF_EEODB		0x78
 #define CTA_EXT_DB_HF_SCDB		0x79
 
 #define EDID_BASIC_AUDIO	(1 << 6)
@@ -4910,6 +4946,12 @@ static bool cea_db_is_hdmi_forum_vsdb(const struct cea_db *db)
 		cea_db_payload_len(db) >= 7;
 }
 
+static bool cea_db_is_hdmi_forum_eeodb(const void *db)
+{
+	return cea_db_is_extended_tag(db, CTA_EXT_DB_HF_EEODB) &&
+		cea_db_payload_len(db) >= 2;
+}
+
 static bool cea_db_is_microsoft_vsdb(const struct cea_db *db)
 {
 	return cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
@@ -4944,6 +4986,47 @@ static bool cea_db_is_hdmi_hdr_metadata_block(const struct cea_db *db)
 		cea_db_payload_len(db) >= 3;
 }
 
+/*
+ * Get the HF-EEODB override extension block count from EDID.
+ *
+ * The passed in EDID may be partially read, as long as it has at least two
+ * blocks (base block and one extension block) if EDID extension count is > 0.
+ *
+ * Note that this is *not* how you should parse CTA Data Blocks in general; this
+ * is only to handle partially read EDIDs. Normally, use the CTA Data Block
+ * iterators instead.
+ *
+ * References:
+ * - HDMI 2.1 section 10.3.6 HDMI Forum EDID Extension Override Data Block
+ */
+static int edid_hfeeodb_extension_block_count(const struct edid *edid)
+{
+	const u8 *cta;
+
+	/* No extensions according to base block, no HF-EEODB. */
+	if (!edid_extension_block_count(edid))
+		return 0;
+
+	/* HF-EEODB is always in the first EDID extension block only */
+	cta = edid_extension_block_data(edid, 0);
+	if (edid_block_tag(cta) != CEA_EXT || cea_revision(cta) < 3)
+		return 0;
+
+	/* Need to have the data block collection, and at least 3 bytes. */
+	if (cea_db_collection_size(cta) < 3)
+		return 0;
+
+	/*
+	 * Sinks that include the HF-EEODB in their E-EDID shall include one and
+	 * only one instance of the HF-EEODB in the E-EDID, occupying bytes 4
+	 * through 6 of Block 1 of the E-EDID.
+	 */
+	if (!cea_db_is_hdmi_forum_eeodb(&cta[4]))
+		return 0;
+
+	return cta[4 + 2];
+}
+
 static void drm_parse_y420cmdb_bitmap(struct drm_connector *connector,
 				      const u8 *db)
 {
-- 
2.30.2


  parent reply	other threads:[~2022-06-22 11:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22 10:59 [Intel-gfx] [PATCH v3 00/13] drm/edid: expand on struct drm_edid usage Jani Nikula
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 01/13] drm/edid: move drm_connector_update_edid_property() to drm_edid.c Jani Nikula
2022-06-22 14:37   ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 02/13] drm/edid: convert drm_connector_update_edid_property() to struct drm_edid Jani Nikula
2022-06-22 14:38   ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 03/13] drm/edid: clean up connector update error handling and debug logging Jani Nikula
2022-06-22 14:40   ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 04/13] drm/edid: abstract debugfs override EDID set/reset Jani Nikula
2022-06-22 14:41   ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 05/13] drm/edid: add drm_edid_connector_update() Jani Nikula
2022-06-22 15:17   ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 06/13] drm/probe-helper: add drm_connector_helper_get_modes() Jani Nikula
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 07/13] drm/edid: add drm_edid_raw() to access the raw EDID data Jani Nikula
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 08/13] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid Jani Nikula
2022-06-22 15:05   ` Ville Syrjälä
2022-06-23  7:29     ` Jani Nikula
2022-06-23  7:27   ` [Intel-gfx] [PATCH] " Jani Nikula
2022-06-23  9:20     ` Ville Syrjälä
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 09/13] drm/i915/bios: convert intel_bios_init_panel() " Jani Nikula
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 10/13] drm/edid: do invalid block filtering in-place Jani Nikula
2022-06-22 10:59 ` Jani Nikula [this message]
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 12/13] drm/edid: take HF-EEODB extension count into account Jani Nikula
2022-06-22 10:59 ` [Intel-gfx] [PATCH v3 13/13] drm/todo: add entry for converting the subsystem to struct drm_edid Jani Nikula
2022-06-22 21:38 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev4) Patchwork
2022-06-22 21:38 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-22 21:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-23  7:56 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev5) Patchwork
2022-06-23  8:18 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-06-23  8:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev6) Patchwork
2022-06-23  9:26 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-27 10:41 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: expand on struct drm_edid usage (rev4) Patchwork
2022-06-27 13:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: expand on struct drm_edid usage (rev6) Patchwork
2022-06-28 20:49 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev7) Patchwork
2022-06-28 20:49 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-28 21:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-29 13:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d35ece8746bf31d2f54ecd540fe57db18764d5ae.1655895388.git.jani.nikula@intel.com \
    --to=jani.nikula@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox