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
next prev 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