From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v7 11/22] drm/edid: split HDMI VSDB info and mode parsing
Date: Wed, 18 Jan 2023 18:08:34 +0200 [thread overview]
Message-ID: <Y8gZgi6+h0ZyDGuE@intel.com> (raw)
In-Reply-To: <7c912a01272a6203673c04eec13158051aafc7dd.1672826282.git.jani.nikula@intel.com>
On Wed, Jan 04, 2023 at 12:05:26PM +0200, Jani Nikula wrote:
> Separate the parsing of display info and modes from the HDMI VSDB. This
> is prerequisite work for overall better separation of the two parsing
> steps.
>
> The info parsing is about figuring out whether the sink supports HDMI
> infoframes. Since they were added in HDMI 1.4, assume the sink supports
> HDMI infoframes if it uses HDMI 1.4 features in HDMI VSDB. For details,
> see commit f1781e9bb2dd ("drm/edid: Allow HDMI infoframe without VIC or
> S3D").
>
> The logic is not exactly the same, but since it was somewhat heuristic
> to begin with, assume this is close enough.
>
> Add cea_db_raw_size() helper to get the size of the entire data block,
> including tag and length. This is helpful for checking against specs
> that define indexes from the start of the entire block, like here.
I do wonder how much point there is in this difference between
the payload handling for HDMI vs. CTA specified blocks. CTA
specifies the bytes using 1-based indexing so the indices won't
directly match the spec there either. Perhaps we should just use
the same approach for all data blocks regardless of where they're
specified. Anyways, just food for thought in the future.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/drm_edid.c | 39 +++++++++++++++++++++++++++++++++++---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 93067b8dd9f6..5cb1d36ce48a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4717,7 +4717,6 @@ static int hdmi_vsdb_latency_length(const u8 *db)
> static int
> do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> {
> - struct drm_display_info *info = &connector->display_info;
> int modes = 0, offset = 0, i, multi_present = 0, multi_len;
> u8 vic_len, hdmi_3d_len = 0;
> u16 mask;
> @@ -4835,8 +4834,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> }
>
> out:
> - if (modes > 0)
> - info->has_hdmi_infoframe = true;
> return modes;
> }
>
> @@ -4893,6 +4890,7 @@ static int cea_db_tag(const struct cea_db *db)
> return db->tag_length >> 5;
> }
>
> +/* Data block payload length excluding the tag and length byte */
> static int cea_db_payload_len(const void *_db)
> {
> /* FIXME: Transition to passing struct cea_db * everywhere. */
> @@ -4901,6 +4899,12 @@ static int cea_db_payload_len(const void *_db)
> return db->tag_length & 0x1f;
> }
>
> +/* Data block raw size including the tag and length byte */
> +static int cea_db_raw_size(const void *db)
> +{
> + return cea_db_payload_len(db) + 1;
> +}
> +
> static const void *cea_db_data(const struct cea_db *db)
> {
> return db->data;
> @@ -6159,6 +6163,32 @@ static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> }
> }
>
> +/*
> + * Try to infer whether the sink supports HDMI infoframes.
> + *
> + * HDMI infoframe support was first added in HDMI 1.4. Assume the sink supports
> + * infoframes if the HDMI VSDB contains HDMI 1.4 features.
> + */
> +static bool hdmi_vsdb_infoframe_support(struct drm_connector *connector, const u8 *db)
> +{
> + int size = cea_db_raw_size(db);
> + int offset = 8;
> +
> + if (offset < size)
> + offset += hdmi_vsdb_latency_length(db);
> +
> + /* 3D_present */
> + if (offset < size && db[offset++] & BIT(7))
> + return true;
> +
> + /* HDMI_VIC_LEN and HDMI_3D_LEN */
> + if (offset < size && db[offset])
> + return true;
I'm thinking it should be enough to just check the HDMI_Video_present
bit. Granted it would be a slight change in behaviour if there are
EDIDs with said bit set but with no actual 3D/HDMI modes included. But
such sinks would still conform to spec version 1.4 and so should have
no problems with the infoframe.
> +
> + return false;
> +}
> +
> +/* HDMI Vendor-Specific Data Block (HDMI VSDB, H14b-VSDB) */
> static void
> drm_parse_hdmi_vsdb_video(struct drm_connector *connector, const u8 *db)
> {
> @@ -6172,6 +6202,9 @@ drm_parse_hdmi_vsdb_video(struct drm_connector *connector, const u8 *db)
> if (len >= 7)
> info->max_tmds_clock = db[7] * 5000;
>
> + if (hdmi_vsdb_infoframe_support(connector, db))
> + info->has_hdmi_infoframe = true;
> +
> drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] HDMI: DVI dual %d, max TMDS clock %d kHz\n",
> connector->base.id, connector->name,
> info->dvi_dual, info->max_tmds_clock);
> --
> 2.34.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-01-18 16:08 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 10:05 [Intel-gfx] [PATCH v7 00/22] drm/edid: info & modes parsing and drm_edid refactors Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 01/22] drm/edid: fix AVI infoframe aspect ratio handling Jani Nikula
2023-01-18 14:56 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 02/22] drm/edid: fix parsing of 3D modes from HDMI VSDB Jani Nikula
2023-01-18 15:00 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 03/22] drm/edid: parse VICs from CTA VDB early Jani Nikula
2023-01-18 15:12 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 04/22] drm/edid: Use the pre-parsed VICs Jani Nikula
2023-01-18 15:08 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 05/22] drm/edid: use VIC in AVI infoframe if sink lists it in CTA VDB Jani Nikula
2023-01-18 15:18 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 06/22] drm/edid: rename struct drm_display_info *display to *info Jani Nikula
2023-01-18 15:19 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 07/22] drm/edid: refactor CTA Y420CMDB parsing Jani Nikula
2023-01-18 15:24 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 08/22] drm/edid: split CTA Y420VDB info and mode parsing Jani Nikula
2023-01-18 15:32 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 09/22] drm/edid: fix and clarify HDMI VSDB audio latency parsing Jani Nikula
2023-01-18 15:41 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 10/22] drm/edid: add helper for HDMI VSDB audio latency field length Jani Nikula
2023-01-18 15:42 ` Ville Syrjälä
2023-01-19 9:44 ` Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 11/22] drm/edid: split HDMI VSDB info and mode parsing Jani Nikula
2023-01-18 16:08 ` Ville Syrjälä [this message]
2023-01-19 15:46 ` [Intel-gfx] [PATCH] " Jani Nikula
2023-01-19 15:59 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 12/22] drm/edid: store quirks in display info Jani Nikula
2023-01-18 16:09 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 13/22] drm/edid: stop passing quirks around Jani Nikula
2023-01-18 16:09 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 14/22] drm/edid: merge ELD handling to update_display_info() Jani Nikula
2023-01-18 16:14 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 15/22] drm/edid: move EDID BPC quirk application " Jani Nikula
2023-01-18 16:15 ` Ville Syrjälä
2023-01-19 12:16 ` Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 16/22] drm/edid: refactor _drm_edid_connector_update() and rename Jani Nikula
2023-01-19 12:19 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 17/22] drm/edid: add separate drm_edid_connector_add_modes() Jani Nikula
2023-01-19 12:23 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 18/22] drm/edid: remove redundant _drm_connector_update_edid_property() Jani Nikula
2023-01-19 12:23 ` Ville Syrjälä
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 19/22] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 20/22] drm/i915/bios: convert intel_bios_init_panel() " Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 21/22] drm/i915/opregion: convert intel_opregion_get_edid() to struct drm_edid Jani Nikula
2023-01-04 10:05 ` [Intel-gfx] [PATCH v7 22/22] drm/i915/panel: move panel fixed EDID to struct intel_panel Jani Nikula
2023-01-04 10:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: info & modes parsing and drm_edid refactors Patchwork
2023-01-04 10:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-01-19 15:49 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/edid: info & modes parsing and drm_edid refactors (rev2) 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=Y8gZgi6+h0ZyDGuE@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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