All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets
Date: Tue, 23 Aug 2022 20:15:48 +0300	[thread overview]
Message-ID: <87mtbukhiz.fsf@intel.com> (raw)
In-Reply-To: <20220819092728.14753-1-ville.syrjala@linux.intel.com>

On Fri, 19 Aug 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> EDID 1.4 introduced some extra flags in the range
> descriptor to support min/max h/vfreq >= 255. Consult them
> to correctly parse the vfreq limits.
>
> Cc: stable@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 24 ++++++++++++++++++------
>  include/drm/drm_edid.h     |  5 +++++
>  2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 90a5e26eafa8..4005dab6147d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6020,12 +6020,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>  }
>  
>  static
> -void get_monitor_range(const struct detailed_timing *timing,
> -		       void *info_monitor_range)
> +void get_monitor_range(const struct detailed_timing *timing, void *c)
>  {
> -	struct drm_monitor_range_info *monitor_range = info_monitor_range;
> +	struct detailed_mode_closure *closure = c;
> +	struct drm_display_info *info = &closure->connector->display_info;
> +	struct drm_monitor_range_info *monitor_range = &info->monitor_range;
>  	const struct detailed_non_pixel *data = &timing->data.other_data;
>  	const struct detailed_data_monitor_range *range = &data->data.range;
> +	const struct edid *edid = closure->drm_edid->edid;
>  
>  	if (!is_display_descriptor(timing, EDID_DETAIL_MONITOR_RANGE))
>  		return;
> @@ -6041,18 +6043,28 @@ void get_monitor_range(const struct detailed_timing *timing,
>  
>  	monitor_range->min_vfreq = range->min_vfreq;
>  	monitor_range->max_vfreq = range->max_vfreq;
> +
> +	if (edid->revision >= 4) {
> +		if (data->pad2 & DRM_EDID_RANGE_OFFSET_MIN_VFREQ)
> +			monitor_range->min_vfreq += 255;
> +		if (data->pad2 & DRM_EDID_RANGE_OFFSET_MAX_VFREQ)
> +			monitor_range->max_vfreq += 255;
> +	}

Nitpick, a combo where min vertical range has +255 offset but max
doesn't shouldn't be okay. But then, what are we going to do in that
case anyway? I guess the generic check would be min <= max. Also, the
+255 offset range is 256..510, not 256..(255+255). Again, what to do if
that's what the EDID has? *shrug*.

Anyway, what's broken here (and probably impacts the testing in the
referenced bug) is that the struct drm_monitor_range_info members are u8
and this overflows.

With that fixed, whether or not you decide to do anything about the
nitpicks,

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


Side note, git grep for monitor_range reveals amdgpu are doing their own
thing for the parsing. *sigh*.


>  }
>  
>  static void drm_get_monitor_range(struct drm_connector *connector,
>  				  const struct drm_edid *drm_edid)
>  {
> -	struct drm_display_info *info = &connector->display_info;
> +	const struct drm_display_info *info = &connector->display_info;
> +	struct detailed_mode_closure closure = {
> +		.connector = connector,
> +		.drm_edid = drm_edid,
> +	};
>  
>  	if (!version_greater(drm_edid, 1, 1))
>  		return;
>  
> -	drm_for_each_detailed_block(drm_edid, get_monitor_range,
> -				    &info->monitor_range);
> +	drm_for_each_detailed_block(drm_edid, get_monitor_range, &closure);
>  
>  	DRM_DEBUG_KMS("Supported Monitor Refresh rate range is %d Hz - %d Hz\n",
>  		      info->monitor_range.min_vfreq,
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 2181977ae683..d81da97cad6e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -92,6 +92,11 @@ struct detailed_data_string {
>  	u8 str[13];
>  } __attribute__((packed));
>  
> +#define DRM_EDID_RANGE_OFFSET_MIN_VFREQ (1 << 0)
> +#define DRM_EDID_RANGE_OFFSET_MAX_VFREQ (1 << 1)
> +#define DRM_EDID_RANGE_OFFSET_MIN_HFREQ (1 << 2)
> +#define DRM_EDID_RANGE_OFFSET_MAX_HFREQ (1 << 3)
> +
>  #define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG   0x00
>  #define DRM_EDID_RANGE_LIMITS_ONLY_FLAG     0x01
>  #define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02

-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets
Date: Tue, 23 Aug 2022 20:15:48 +0300	[thread overview]
Message-ID: <87mtbukhiz.fsf@intel.com> (raw)
In-Reply-To: <20220819092728.14753-1-ville.syrjala@linux.intel.com>

On Fri, 19 Aug 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> EDID 1.4 introduced some extra flags in the range
> descriptor to support min/max h/vfreq >= 255. Consult them
> to correctly parse the vfreq limits.
>
> Cc: stable@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 24 ++++++++++++++++++------
>  include/drm/drm_edid.h     |  5 +++++
>  2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 90a5e26eafa8..4005dab6147d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6020,12 +6020,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>  }
>  
>  static
> -void get_monitor_range(const struct detailed_timing *timing,
> -		       void *info_monitor_range)
> +void get_monitor_range(const struct detailed_timing *timing, void *c)
>  {
> -	struct drm_monitor_range_info *monitor_range = info_monitor_range;
> +	struct detailed_mode_closure *closure = c;
> +	struct drm_display_info *info = &closure->connector->display_info;
> +	struct drm_monitor_range_info *monitor_range = &info->monitor_range;
>  	const struct detailed_non_pixel *data = &timing->data.other_data;
>  	const struct detailed_data_monitor_range *range = &data->data.range;
> +	const struct edid *edid = closure->drm_edid->edid;
>  
>  	if (!is_display_descriptor(timing, EDID_DETAIL_MONITOR_RANGE))
>  		return;
> @@ -6041,18 +6043,28 @@ void get_monitor_range(const struct detailed_timing *timing,
>  
>  	monitor_range->min_vfreq = range->min_vfreq;
>  	monitor_range->max_vfreq = range->max_vfreq;
> +
> +	if (edid->revision >= 4) {
> +		if (data->pad2 & DRM_EDID_RANGE_OFFSET_MIN_VFREQ)
> +			monitor_range->min_vfreq += 255;
> +		if (data->pad2 & DRM_EDID_RANGE_OFFSET_MAX_VFREQ)
> +			monitor_range->max_vfreq += 255;
> +	}

Nitpick, a combo where min vertical range has +255 offset but max
doesn't shouldn't be okay. But then, what are we going to do in that
case anyway? I guess the generic check would be min <= max. Also, the
+255 offset range is 256..510, not 256..(255+255). Again, what to do if
that's what the EDID has? *shrug*.

Anyway, what's broken here (and probably impacts the testing in the
referenced bug) is that the struct drm_monitor_range_info members are u8
and this overflows.

With that fixed, whether or not you decide to do anything about the
nitpicks,

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


Side note, git grep for monitor_range reveals amdgpu are doing their own
thing for the parsing. *sigh*.


>  }
>  
>  static void drm_get_monitor_range(struct drm_connector *connector,
>  				  const struct drm_edid *drm_edid)
>  {
> -	struct drm_display_info *info = &connector->display_info;
> +	const struct drm_display_info *info = &connector->display_info;
> +	struct detailed_mode_closure closure = {
> +		.connector = connector,
> +		.drm_edid = drm_edid,
> +	};
>  
>  	if (!version_greater(drm_edid, 1, 1))
>  		return;
>  
> -	drm_for_each_detailed_block(drm_edid, get_monitor_range,
> -				    &info->monitor_range);
> +	drm_for_each_detailed_block(drm_edid, get_monitor_range, &closure);
>  
>  	DRM_DEBUG_KMS("Supported Monitor Refresh rate range is %d Hz - %d Hz\n",
>  		      info->monitor_range.min_vfreq,
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 2181977ae683..d81da97cad6e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -92,6 +92,11 @@ struct detailed_data_string {
>  	u8 str[13];
>  } __attribute__((packed));
>  
> +#define DRM_EDID_RANGE_OFFSET_MIN_VFREQ (1 << 0)
> +#define DRM_EDID_RANGE_OFFSET_MAX_VFREQ (1 << 1)
> +#define DRM_EDID_RANGE_OFFSET_MIN_HFREQ (1 << 2)
> +#define DRM_EDID_RANGE_OFFSET_MAX_HFREQ (1 << 3)
> +
>  #define DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG   0x00
>  #define DRM_EDID_RANGE_LIMITS_ONLY_FLAG     0x01
>  #define DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2022-08-23 18:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  9:27 [PATCH] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets Ville Syrjala
2022-08-19  9:27 ` [Intel-gfx] " Ville Syrjala
2022-08-23 16:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-08-23 17:15 ` Jani Nikula [this message]
2022-08-23 17:15   ` [Intel-gfx] [PATCH] " Jani Nikula
2022-08-24 12:11   ` Ville Syrjälä
2022-08-24 12:11     ` Ville Syrjälä
2022-08-24 12:11     ` [Intel-gfx] " Ville Syrjälä
2022-08-24 13:46 ` [PATCH v2] " Ville Syrjala
2022-08-24 13:46   ` Ville Syrjala
2022-08-24 13:46   ` [Intel-gfx] " Ville Syrjala
2022-08-24 15:11 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2022-08-24 16:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets (rev2) Patchwork
2022-08-26  8:00 ` [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=87mtbukhiz.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.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.