From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v1 11/13] drm/edid: add HF-EEODB support to EDID read and allocation
Date: Tue, 07 Jun 2022 14:26:06 +0300 [thread overview]
Message-ID: <87ilpcpve9.fsf@intel.com> (raw)
In-Reply-To: <YppBTAFXSNgaoymG@intel.com>
On Fri, 03 Jun 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Tue, May 24, 2022 at 01:39:33PM +0300, Jani Nikula wrote:
>> 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.
>>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>> drivers/gpu/drm/drm_edid.c | 81 ++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 78 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 5e0a91da565e..ba0c880dc133 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);
>>
>> @@ -2235,7 +2249,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;
>>
>> @@ -2277,7 +2291,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);
>> @@ -2288,11 +2303,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);
>> }
>> @@ -3825,6 +3860,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)
>> @@ -4868,6 +4904,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) &&
>> @@ -4902,6 +4944,39 @@ 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.
>> + *
>> + * 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;
>> +
>> + /*
>> + * 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;
>
> Still not a big fan of these hardcoded things. Not sure if there's any
> easy way to just use the normal iterators at this point when we don't
> really know the full composition of the EDID yet. If not then I guess
> we'll have to use some hardcoded stuff. What we definitely seem to be
> missing here are size checks, for both the whoe data block collection,
> and the specific data block payload.
I don't like it either, but it's a chicken and egg problem wrt how far
to iterate. Taking this into account in the iterators looks like making
the iterators harder to understand, so I prefer the hardcoded hack here
in one place. And the spec specifically says where this data block must
be.
The data block collection size check is an oversight, but
cea_db_is_hdmi_forum_eeodb() does check for minimum payload length.
BR,
Jani.
>
>> +
>> + return cta[4 + 2];
>> +}
>> +
>> static void drm_parse_y420cmdb_bitmap(struct drm_connector *connector,
>> const u8 *db)
>> {
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-06-07 11:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 10:39 [Intel-gfx] [PATCH v1 00/13] drm/edid: expand on struct drm_edid usage Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid Jani Nikula
2022-05-24 13:29 ` Andrzej Hajda
2022-05-24 13:41 ` Jani Nikula
2022-06-02 16:54 ` Ville Syrjälä
2022-06-02 17:08 ` Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 02/13] drm/edid: keep track of alloc size in drm_do_get_edid() Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 03/13] drm/edid: add new interfaces around struct drm_edid Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 04/13] drm/edid: add drm_edid_connector_update() Jani Nikula
2022-06-02 17:09 ` Ville Syrjälä
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 05/13] drm/probe-helper: abstract .get_modes() connector helper call Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 06/13] drm/probe-helper: make .get_modes() optional, add default action Jani Nikula
2022-06-02 17:14 ` Ville Syrjälä
2022-06-07 11:14 ` Jani Nikula
2022-06-07 19:43 ` Ville Syrjälä
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 07/13] drm/probe-helper: add .get_edid() callback Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 08/13] drm/edid: add drm_edid_raw() to access the raw EDID data Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 09/13] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 10/13] drm/edid: do invalid block filtering in-place Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 11/13] drm/edid: add HF-EEODB support to EDID read and allocation Jani Nikula
2022-06-03 17:13 ` Ville Syrjälä
2022-06-07 11:26 ` Jani Nikula [this message]
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 12/13] drm/edid: take HF-EEODB extension count into account Jani Nikula
2022-05-24 10:39 ` [Intel-gfx] [PATCH v1 13/13] drm/todo: add entry for converting the subsystem to struct drm_edid Jani Nikula
2022-05-24 11:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage Patchwork
2022-05-24 11:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-24 11:34 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-05-24 11:37 ` Jani Nikula
2022-05-24 11:41 ` Sarvela, Tomi P
2022-05-25 8:48 ` Jani Nikula
2022-05-24 15:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev2) Patchwork
2022-05-24 15:58 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-24 19:58 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-24 22:25 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87ilpcpve9.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/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