All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org,
	Dmitry Osipenko <dmitry.osipenko@collabora.com>
Subject: Re: [PATCH] drm/edid: Parse topology block for all DispID structure v1.x
Date: Fri, 12 Apr 2024 11:25:57 +0300	[thread overview]
Message-ID: <87pluv3s2y.fsf@intel.com> (raw)
In-Reply-To: <20240410180139.21352-1-ville.syrjala@linux.intel.com>

On Wed, 10 Apr 2024, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> DisplayID spec v1.3 revision history notes do claim that
> the toplogy block was added in v1.3 so requiring structure
> v1.2 would seem correct, but there is at least one EDID in
> edid.tv with a topology block and structure v1.0. And
> there are also EDIDs with DisplayID structure v1.3 which
> seems to be totally incorrect as DisplayID spec v1.3 lists
> structure v1.2 as the only legal value.
>
> Unfortunately I couldn't find copies of DisplayID spec
> v1.0-v1.2 anywhere (even on vesa.org), so I'll have to
> go on empirical evidence alone.
>
> We used to parse the topology block on all v1.x
> structures until the check for structure v2.0 was added.
> Let's go back to doing that as the evidence does suggest
> that there are DisplayIDs in the wild that would miss
> out on the topology stuff otherwise.
>
> Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as
> it doesn't appear we can really use it for anything.
>
> I *think* we could technically skip all the structure
> version checks as the block tags shouldn't conflict
> between v2.0 and v1.x. But no harm in having a bit of
> extra sanity checks I guess.

Our checks for the data block tags is pretty haphazard, and we should
clean this up across the board. For some things we check only the tag
for one version or the other, for some things we check both tags but
without the version check, and for some things (like this one here) we
do check version and tag. The CTA checks rely on the fact that
DATA_BLOCK_CTA == DATA_BLOCK_2_CTA_DISPLAY_ID.

It's a mess.

I've thought about adding a helper that would check version & 0xf0 when
checking block tags, and where you could check for one or the other or
both versions.

Like, quickly drafting,

#define NOPE -1

bool is_block(int tag_to_check, int ver, int tag_v1, int tag_v2)
{
	if ((ver & 0xf0) == 1 && tag_v1 != NOPE && tag_v1 == tag_to_check)
		return true;
	if ((ver & 0xf0) == 2 && tag_v2 != NOPE && tag_v2 == tag_to_check)
		return true;
        return false;
}

And then something like:

	if (is_block(tag, version, DATA_BLOCK_FOO, DATA_BLOCK_2_FOO))
		...

or

	if (is_block(tag, version, NOPE, DATA_BLOCK_2_FOO))
		...

Or just pass iter and block like for displayid_is_tiled_block().

IDK if that becomes unwieldy at the call sites. Maybe we'll need
additional specific helpers like displayid_is_tiled_block() on top.

Anyway, on the patch at hand,

Acked-by: Jani Nikula <jani.nikula@intel.com>


>
> So far I'm not aware of any user reported regressions
> from overly strict check, but I do know that it broke
> igt/kms_tiled_display's fake DisplayID as that one
> gets generated with structure v1.0.
>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c  | 2 +-
>  include/drm/drm_displayid.h | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ea77577a3786..f0948ab214b3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -7405,7 +7405,7 @@ static void drm_parse_tiled_block(struct drm_connector *connector,
>  static bool displayid_is_tiled_block(const struct displayid_iter *iter,
>  				     const struct displayid_block *block)
>  {
> -	return (displayid_version(iter) == DISPLAY_ID_STRUCTURE_VER_12 &&
> +	return (displayid_version(iter) < DISPLAY_ID_STRUCTURE_VER_20 &&
>  		block->tag == DATA_BLOCK_TILED_DISPLAY) ||
>  		(displayid_version(iter) == DISPLAY_ID_STRUCTURE_VER_20 &&
>  		 block->tag == DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY);
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
> index 566497eeb3b8..bc1f6b378195 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -30,7 +30,6 @@ struct drm_edid;
>  #define VESA_IEEE_OUI				0x3a0292
>  
>  /* DisplayID Structure versions */
> -#define DISPLAY_ID_STRUCTURE_VER_12		0x12
>  #define DISPLAY_ID_STRUCTURE_VER_20		0x20
>  
>  /* DisplayID Structure v1r2 Data Blocks */

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2024-04-12  8:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-10 18:01 [PATCH] drm/edid: Parse topology block for all DispID structure v1.x Ville Syrjala
2024-04-10 21:29 ` ✗ Fi.CI.BAT: failure for " Patchwork
2024-04-12  8:25 ` Jani Nikula [this message]
2024-04-20  0:21 ` ✓ Fi.CI.BAT: success for drm/edid: Parse topology block for all DispID structure v1.x (rev2) Patchwork
2024-04-20  4:02 ` ✓ 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=87pluv3s2y.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=dmitry.osipenko@collabora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.