Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Lee Shawn C <shawn.c.lee@intel.com>, dri-devel@lists.freedesktop.org
Cc: Drew Davenport <ddavenport@chromium.org>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [v7 3/5] drm/edid: read HF-EEODB ext block
Date: Tue, 15 Mar 2022 13:03:19 +0200	[thread overview]
Message-ID: <87y21btr48.fsf@intel.com> (raw)
In-Reply-To: <20220313134702.24175-4-shawn.c.lee@intel.com>

On Sun, 13 Mar 2022, Lee Shawn C <shawn.c.lee@intel.com> wrote:
> According to HDMI 2.1 spec.
>
> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> is utilized by Sink Devices to provide an alternate method to
> indicate an EDID Extension Block count larger than 1, while
> avoiding the need to present a VESA Block Map in the first
> E-EDID Extension Block."
>
> It is a mandatory for HDMI 2.1 protocol compliance as well.
> This patch help to know how many HF_EEODB blocks report by sink
> and read allo HF_EEODB blocks back.
>
> v2: support to find CEA block, check EEODB block format, and return
>     available block number in drm_edid_read_hf_eeodb_blk_count().
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Cc: Drew Davenport <ddavenport@chromium.org>
> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c |  8 +++-
>  drivers/gpu/drm/drm_edid.c      | 71 +++++++++++++++++++++++++++++++--
>  include/drm/drm_edid.h          |  1 +
>  3 files changed, 74 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2f..16011023c12e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2129,7 +2129,7 @@ int drm_connector_update_edid_property(struct drm_connector *connector,
>  				       const struct edid *edid)
>  {
>  	struct drm_device *dev = connector->dev;
> -	size_t size = 0;
> +	size_t size = 0, hf_eeodb_blk_count;
>  	int ret;
>  	const struct edid *old_edid;
>  
> @@ -2137,8 +2137,12 @@ int drm_connector_update_edid_property(struct drm_connector *connector,
>  	if (connector->override_edid)
>  		return 0;
>  
> -	if (edid)
> +	if (edid) {
>  		size = EDID_LENGTH * (1 + edid->extensions);
> +		hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count(edid);
> +		if (hf_eeodb_blk_count)
> +			size = EDID_LENGTH * (1 + hf_eeodb_blk_count);

This approach does not scale. If the number of extensions and thus the
total EDID size depend on HF-EEODB, this *must* be abstracted.

Consider, for example, drm_edid_duplicate(), which only looks at
edid->extensions. A subsequent HF-EEODB aware access on an EDID
duplicated using drm_edid_duplicate() will access beyond the allocated
buffer.

Yes, it's a lot of work to introduce drm_edid_size() and
drm_edid_extension_count() or similar, and use them everywhere, but this
is what we must do. It's a lot more work to try to take HF-EEODB into
account everywhere. The latter is going to be riddled with bugs with
everyone doing it a little different.

> +	}
>  
>  	/* Set the display info, using edid if available, otherwise
>  	 * resetting the values to defaults. This duplicates the work
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9fa84881fbba..5ae4e83fa5e3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1992,6 +1992,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>  {
>  	int i, j = 0, valid_extensions = 0;
>  	u8 *edid, *new;
> +	size_t hf_eeodb_blk_count;
>  	struct edid *override;
>  
>  	override = drm_get_override_edid(connector);
> @@ -2051,7 +2052,35 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>  		}
>  
>  		kfree(edid);
> +		return (struct edid *)new;
> +	}
> +
> +	hf_eeodb_blk_count = drm_edid_read_hf_eeodb_blk_count((struct edid *)edid);
> +	if (hf_eeodb_blk_count >= 2) {
> +		new = krealloc(edid, (hf_eeodb_blk_count + 1) * EDID_LENGTH, GFP_KERNEL);
> +		if (!new)
> +			goto out;
>  		edid = new;
> +
> +		valid_extensions = hf_eeodb_blk_count - 1;
> +		for (j = 2; j <= hf_eeodb_blk_count; j++) {
> +			u8 *block = edid + j * EDID_LENGTH;
> +
> +			for (i = 0; i < 4; i++) {
> +				if (get_edid_block(data, block, j, EDID_LENGTH))
> +					goto out;
> +				if (drm_edid_block_valid(block, j, false, NULL))
> +					break;
> +			}
> +
> +			if (i == 4)
> +				valid_extensions--;
> +		}
> +
> +		if (valid_extensions != hf_eeodb_blk_count - 1) {
> +			DRM_ERROR("Not able to retrieve proper EDID contain HF-EEODB data.\n");
> +			goto out;
> +		}
>  	}
>  
>  	return (struct edid *)edid;
> @@ -3315,15 +3344,17 @@ add_detailed_modes(struct drm_connector *connector, struct edid *edid,
>  #define VIDEO_BLOCK     0x02
>  #define VENDOR_BLOCK    0x03
>  #define SPEAKER_BLOCK	0x04
> -#define HDR_STATIC_METADATA_BLOCK	0x6
> -#define USE_EXTENDED_TAG 0x07
> -#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> +#define EXT_VIDEO_CAPABILITY_BLOCK	0x00
> +#define HDR_STATIC_METADATA_BLOCK	0x06
> +#define USE_EXTENDED_TAG		0x07
>  #define EXT_VIDEO_DATA_BLOCK_420	0x0E
> -#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> +#define EXT_VIDEO_CAP_BLOCK_Y420CMDB	0x0F
> +#define EXT_VIDEO_HF_EEODB_DATA_BLOCK	0x78
>  #define EDID_BASIC_AUDIO	(1 << 6)
>  #define EDID_CEA_YCRCB444	(1 << 5)
>  #define EDID_CEA_YCRCB422	(1 << 4)
>  #define EDID_CEA_VCDB_QS	(1 << 6)
> +#define HF_EEODB_LENGTH		2
>  
>  /*
>   * Search EDID for CEA extension block.
> @@ -4274,9 +4305,41 @@ static bool cea_db_is_y420vdb(const u8 *db)
>  	return true;
>  }
>  
> +static bool cea_db_is_hdmi_forum_eeodb(const u8 *db)
> +{
> +	if (cea_db_tag(db) != USE_EXTENDED_TAG)
> +		return false;
> +
> +	if (cea_db_payload_len(db) != HF_EEODB_LENGTH)
> +		return false;
> +
> +	if (cea_db_extended_tag(db) != EXT_VIDEO_HF_EEODB_DATA_BLOCK)
> +		return false;
> +
> +	return true;
> +}
> +
>  #define for_each_cea_db(cea, i, start, end) \
>  	for ((i) = (start); (i) < (end) && (i) + cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) + 1)
>  
> +size_t drm_edid_read_hf_eeodb_blk_count(const struct edid *edid)
> +{
> +	const u8 *cea;
> +	int i, start, end, cea_ext_index = 0, displayid_ext_index = 0;
> +
> +	if (edid->extensions) {
> +		cea = drm_find_cea_extension(edid, &cea_ext_index, &displayid_ext_index);
> +
> +		if (cea && !cea_db_offsets(cea, &start, &end))
> +			for_each_cea_db(cea, i, start, end)
> +				if (cea_db_is_hdmi_forum_eeodb(&cea[i]))
> +					return cea[i + 2];
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_edid_read_hf_eeodb_blk_count);

This should be static and not exported.

BR,
Jani.

> +
>  static void drm_parse_y420cmdb_bitmap(struct drm_connector *connector,
>  				      const u8 *db)
>  {
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 144c495b99c4..585f0ed932d4 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -593,5 +593,6 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
>  const u8 *drm_find_edid_extension(const struct edid *edid,
>  				  int ext_id, int *ext_index);
>  
> +size_t drm_edid_read_hf_eeodb_blk_count(const struct edid *edid);
>  
>  #endif /* __DRM_EDID_H__ */

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-03-15 11:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 13:46 [Intel-gfx] [v7 0/5] enhanced edid driver compatibility Lee Shawn C
2022-03-13 13:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for enhanced edid driver compatibility (rev3) Patchwork
2022-03-13 13:46 ` [Intel-gfx] [v7 1/5] drm/edid: seek for available CEA and DisplayID block from specific EDID block index Lee Shawn C
2022-03-14  8:40   ` Jani Nikula
2022-03-14 21:02     ` Drew Davenport
2022-03-15 12:32       ` Jani Nikula
2022-03-15 15:21         ` Lee, Shawn C
2022-03-15 17:22           ` Drew Davenport
2022-03-13 13:46 ` [Intel-gfx] [v7 2/5] drm/edid: parse multiple CEA extension block Lee Shawn C
2022-03-13 13:47 ` [Intel-gfx] [v7 3/5] drm/edid: read HF-EEODB ext block Lee Shawn C
2022-03-15 11:03   ` Jani Nikula [this message]
2022-03-15 13:43     ` Lee, Shawn C
2022-03-13 13:47 ` [Intel-gfx] [v7 4/5] drm/edid: parse HF-EEODB CEA extension block Lee Shawn C
2022-03-13 13:47 ` [Intel-gfx] [v7 5/5] drm/edid: check for HF-SCDB block Lee Shawn C
2022-03-13 13:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for enhanced edid driver compatibility (rev3) Patchwork
2022-03-13 14:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-13 15:24 ` [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=87y21btr48.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=ddavenport@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shawn.c.lee@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