All of lore.kernel.org
 help / color / mirror / Atom feed
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: [PATCH v2 01/15] drm/edid: fix CTA data block collection size for CTA version 3
Date: Fri, 10 Jun 2022 21:56:58 +0300	[thread overview]
Message-ID: <YqOT+qvLv0TqtPOL@intel.com> (raw)
In-Reply-To: <2a4c94417f024cbafc5d4ca0a74e4617fc4325d1.1654674560.git.jani.nikula@intel.com>

On Wed, Jun 08, 2022 at 10:50:31AM +0300, Jani Nikula wrote:
> The CTA Data Block Collection is valid only for CTA extension version
> 3. In versions 1 and 2, it is a reserved block, which we ignore.
> 
> The DTD start offset (byte 2, or d in CTA-861 spec), which determines
> the CTA Data Block Collection size, is specified slightly differently
> for different versions:
> 
> Version 1:
>     d = offset for the byte following the reserved data block. If no
>     data is provided in the reserved data block, then d=4. If no DTDs
>     are provided, then d=0
> 
> Version 2:
>     d = offset for the byte following the reserved data block. If no
>     data is provided in the reserved data block, then d=4. If d=0, then
>     no detailed timing descriptors are provided, and no data is provided
>     in the reserved data block.
> 
> Version 3:
>     d = offset for the byte following the data block collection. If no
>     data is provided in the data block collection, then d=4. If d=0,
>     then no detailed timing descriptors are provided, and no data is
>     provided in the data block collection.
> 
> Ever since commit 9e50b9d55e9c ("drm: edid: Add some bounds checking"),
> we've interpreted 0 to mean there are no DTDs but it's all Data
> Blocks. Per the spec, Data Blocks are only valid for version 3, where we
> should interpret 0 to mean there are no data blocks.
> 
> Follow the spec (and hope the EDIDs follow it too).
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 929fc0e46751..c57f6333ea7d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4498,8 +4498,6 @@ static const void *__cea_db_iter_edid_next(struct cea_db_iter *iter)
>  
>  		iter->index = 4;
>  		iter->end = ext[2];
> -		if (iter->end == 0)
> -			iter->end = 127;

Not really sure how I came up with this interpretation of the spec.

Looks like I at least fixed up the 18byte descriptor parsing
correctly in commit 7304b9810a73 ("drm/edid: Check the number
of detailed timing descriptors in the CEA ext block")

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

>  		if (iter->end < 4 || iter->end > 127)
>  			continue;
>  
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
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 v2 01/15] drm/edid: fix CTA data block collection size for CTA version 3
Date: Fri, 10 Jun 2022 21:56:58 +0300	[thread overview]
Message-ID: <YqOT+qvLv0TqtPOL@intel.com> (raw)
In-Reply-To: <2a4c94417f024cbafc5d4ca0a74e4617fc4325d1.1654674560.git.jani.nikula@intel.com>

On Wed, Jun 08, 2022 at 10:50:31AM +0300, Jani Nikula wrote:
> The CTA Data Block Collection is valid only for CTA extension version
> 3. In versions 1 and 2, it is a reserved block, which we ignore.
> 
> The DTD start offset (byte 2, or d in CTA-861 spec), which determines
> the CTA Data Block Collection size, is specified slightly differently
> for different versions:
> 
> Version 1:
>     d = offset for the byte following the reserved data block. If no
>     data is provided in the reserved data block, then d=4. If no DTDs
>     are provided, then d=0
> 
> Version 2:
>     d = offset for the byte following the reserved data block. If no
>     data is provided in the reserved data block, then d=4. If d=0, then
>     no detailed timing descriptors are provided, and no data is provided
>     in the reserved data block.
> 
> Version 3:
>     d = offset for the byte following the data block collection. If no
>     data is provided in the data block collection, then d=4. If d=0,
>     then no detailed timing descriptors are provided, and no data is
>     provided in the data block collection.
> 
> Ever since commit 9e50b9d55e9c ("drm: edid: Add some bounds checking"),
> we've interpreted 0 to mean there are no DTDs but it's all Data
> Blocks. Per the spec, Data Blocks are only valid for version 3, where we
> should interpret 0 to mean there are no data blocks.
> 
> Follow the spec (and hope the EDIDs follow it too).
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 929fc0e46751..c57f6333ea7d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4498,8 +4498,6 @@ static const void *__cea_db_iter_edid_next(struct cea_db_iter *iter)
>  
>  		iter->index = 4;
>  		iter->end = ext[2];
> -		if (iter->end == 0)
> -			iter->end = 127;

Not really sure how I came up with this interpretation of the spec.

Looks like I at least fixed up the 18byte descriptor parsing
correctly in commit 7304b9810a73 ("drm/edid: Check the number
of detailed timing descriptors in the CEA ext block")

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

>  		if (iter->end < 4 || iter->end > 127)
>  			continue;
>  
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-06-10 18:57 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08  7:50 [PATCH v2 00/15] drm/edid: expand on struct drm_edid usage Jani Nikula
2022-06-08  7:50 ` [Intel-gfx] " Jani Nikula
2022-06-08  7:50 ` [PATCH v2 01/15] drm/edid: fix CTA data block collection size for CTA version 3 Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 18:56   ` Ville Syrjälä [this message]
2022-06-10 18:56     ` Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 02/15] drm/edid: abstract cea data block collection size Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 18:58   ` Ville Syrjälä
2022-06-10 18:58     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 03/15] drm/edid: add block count and data helper functions for drm_edid Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-08  7:50 ` [PATCH v2 04/15] drm/edid: keep track of alloc size in drm_do_get_edid() Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:35   ` Ville Syrjälä
2022-06-10 19:35     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 05/15] drm/edid: add new interfaces around struct drm_edid Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:35   ` Ville Syrjälä
2022-06-10 19:35     ` [Intel-gfx] " Ville Syrjälä
2022-06-10 19:43   ` Ville Syrjälä
2022-06-10 19:43     ` [Intel-gfx] " Ville Syrjälä
2022-06-13  8:37     ` Jani Nikula
2022-06-13  8:37       ` [Intel-gfx] " Jani Nikula
2022-06-08  7:50 ` [PATCH v2 06/15] drm/edid: add drm_edid_connector_update() Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:15   ` Ville Syrjälä
2022-06-10 19:15     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 07/15] drm/probe-helper: abstract .get_modes() connector helper call Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:36   ` Ville Syrjälä
2022-06-10 19:36     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 08/15] drm/probe-helper: add drm_connector_helper_get_modes() Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:44   ` Ville Syrjälä
2022-06-10 19:44     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 09/15] drm/edid: add drm_edid_raw() to access the raw EDID data Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:29   ` Ville Syrjälä
2022-06-10 19:29     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 10/15] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:21   ` Ville Syrjälä
2022-06-10 19:21     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 11/15] drm/i915/bios: convert intel_bios_init_panel() " Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:29   ` Ville Syrjälä
2022-06-10 19:29     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 12/15] drm/edid: do invalid block filtering in-place Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:30   ` Ville Syrjälä
2022-06-10 19:30     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 13/15] drm/edid: add HF-EEODB support to EDID read and allocation Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:30   ` Ville Syrjälä
2022-06-10 19:30     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 14/15] drm/edid: take HF-EEODB extension count into account Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-10 19:34   ` Ville Syrjälä
2022-06-10 19:34     ` [Intel-gfx] " Ville Syrjälä
2022-06-08  7:50 ` [PATCH v2 15/15] drm/todo: add entry for converting the subsystem to struct drm_edid Jani Nikula
2022-06-08  7:50   ` [Intel-gfx] " Jani Nikula
2022-06-08  8:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev3) Patchwork
2022-06-08  8:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-08 11:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-08 19:23 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-06-13  9:37 ` [PATCH v2 00/15] drm/edid: expand on struct drm_edid usage Jani Nikula
2022-06-13  9:37   ` [Intel-gfx] " Jani Nikula

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=YqOT+qvLv0TqtPOL@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 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.