public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings
Date: Fri, 2 Sep 2022 17:02:00 +0300	[thread overview]
Message-ID: <YxIM2EmoMc1ElSCK@intel.com> (raw)
In-Reply-To: <87edwtevvz.fsf@intel.com>

On Fri, Sep 02, 2022 at 04:41:36PM +0300, Jani Nikula wrote:
> On Sat, 27 Aug 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Prefer the timing formula indicated by the range
> > descriptor for generating the non-DMT standard timings.
> >
> > Previously we just used CVT for all EDID 1.4 continuous
> > frequency displays without even checking if the range
> > descriptor indicates otherwise. Now we check the range
> > descriptor first, and fall back to CVT if nothing else
> > was indicated. EDID 1.4 more or less deprecates GTF/GTF2
> > but there are still a lot of 1.4 EDIDs out there that
> > don't advertise CVT support, so seems safer to use the
> > formula the EDID actually reports as supported.
> >
> > For EDID 1.3 we use GTF2 if indicated (as before), and for
> > EDID 1.2+ we now just use GTF without even checking the
> > feature flag. There seem to be quite a few EDIDs out there that
> > don't set the GTF feature flag but still include a GTF range
> > descriptor and non-DMT standard timings.
> >
> > This to me seems to be roughly what appendix B of EDID 1.4
> > suggests should be done.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_edid.c | 49 +++++++++++++++++++++++++++++++-------
> >  1 file changed, 41 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index fed2bdd55c09..c1c85b9e1208 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3077,20 +3077,53 @@ drm_gtf2_2j(const struct drm_edid *drm_edid)
> >  	return descriptor ? descriptor->data.other_data.data.range.formula.gtf2.j : 0;
> >  }
> >  
> > +static void
> > +get_timing_level(const struct detailed_timing *descriptor, void *data)
> > +{
> > +	int *res = data;
> > +
> > +	if (!is_display_descriptor(descriptor, EDID_DETAIL_MONITOR_RANGE))
> > +		return;
> > +
> > +	BUILD_BUG_ON(offsetof(typeof(*descriptor), data.other_data.data.range.flags) != 10);
> > +
> > +	switch (descriptor->data.other_data.data.range.flags) {
> > +	case DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG:
> > +		*res = LEVEL_GTF;
> > +		break;
> > +	case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG:
> > +		*res = LEVEL_GTF2;
> > +		break;
> > +	case DRM_EDID_CVT_SUPPORT_FLAG:
> > +		*res = LEVEL_CVT;
> > +		break;
> > +	default:
> > +		break;
> > +	}
> > +}
> > +
> >  /* Get standard timing level (CVT/GTF/DMT). */
> >  static int standard_timing_level(const struct drm_edid *drm_edid)
> >  {
> >  	const struct edid *edid = drm_edid->edid;
> >  
> > -	if (edid->revision >= 2) {
> > -		if (edid->revision >= 4 && (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF))
> > -			return LEVEL_CVT;
> > -		if (drm_gtf2_hbreak(drm_edid))
> > -			return LEVEL_GTF2;
> > -		if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
> > -			return LEVEL_GTF;
> > +	if (edid->revision >= 4) {
> > +		/*
> > +		 * If the range descriptor doesn't
> > +		 * indicate otherwise default to CVT
> > +		 */
> > +		int ret = LEVEL_CVT;
> > +
> > +		drm_for_each_detailed_block(drm_edid, get_timing_level, &ret);
> 
> Please remind me why it's okay to iterate all of them and pick the last?
> I mean ret gets overwritten by the last block.

I think there is an implied assumption that there is only
zero or one of these included in the EDID. While not explicitly
stated in the spec, there is no mention anywhere what it would
mean to have multiple different types of range descriptors.
And so far I didn't come across any EDIDs that would disagree with
that.

> 
> Otherwise it all seems okay to me, though I admit my confidence level in
> this review is considerably lower than for the other patches.
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> 
> 
> > +
> > +		return ret;
> > +	} else if (edid->revision >= 3 && drm_gtf2_hbreak(drm_edid)) {
> > +		return LEVEL_GTF2;
> > +	} else if (edid->revision >= 2) {
> > +		return LEVEL_GTF;
> > +	} else {
> > +		return LEVEL_DMT;
> >  	}
> > -	return LEVEL_DMT;
> >  }
> >  
> >  /*
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-09-02 14:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 21:34 [Intel-gfx] [PATCH 00/11] drm/edid: Range descriptor stuff Ville Syrjala
2022-08-26 21:34 ` [Intel-gfx] [PATCH 01/11] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets Ville Syrjala
2022-08-27  1:40   ` Navare, Manasi
2022-09-02 13:44     ` Ville Syrjälä
2022-08-26 21:34 ` [Intel-gfx] [PATCH 02/11] drm/edid: Clarify why we only accept the "range limits only" descriptor Ville Syrjala
2022-08-27  1:45   ` Navare, Manasi
2022-08-26 21:34 ` [Intel-gfx] [PATCH 03/11] drm/edid: s/monitor_rage/vrr_range/ Ville Syrjala
2022-08-27  1:47   ` Navare, Manasi
2022-08-29  8:29   ` Jani Nikula
2022-08-26 21:34 ` [Intel-gfx] [PATCH 04/11] drm/edid: Define more flags Ville Syrjala
2022-08-29  8:39   ` Jani Nikula
2022-08-26 21:34 ` [Intel-gfx] [PATCH 05/11] drm/edid: Only parse VRR range for continuous frequency displays Ville Syrjala
2022-08-29  8:58   ` Jani Nikula
2022-08-26 21:34 ` [Intel-gfx] [PATCH 06/11] drm/edid: Extract drm_gtf2_mode() Ville Syrjala
2022-08-29  8:45   ` Jani Nikula
2022-08-26 21:34 ` [Intel-gfx] [PATCH 07/11] drm/edid: Use GTF2 for inferred modes Ville Syrjala
2022-09-02 12:25   ` Jani Nikula
2022-09-02 12:45     ` Ville Syrjälä
2022-08-26 21:34 ` [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings Ville Syrjala
2022-09-02 13:41   ` Jani Nikula
2022-09-02 14:02     ` Ville Syrjälä [this message]
2022-08-26 21:34 ` [Intel-gfx] [PATCH 09/11] drm/edid: Unconfuse preferred timing stuff a bit Ville Syrjala
2022-09-02 12:27   ` Jani Nikula
2022-08-26 21:35 ` [Intel-gfx] [PATCH 10/11] drm/edid: Make version checks less convoluted Ville Syrjala
2022-09-02 12:31   ` Jani Nikula
2022-08-26 21:35 ` [Intel-gfx] [PATCH 11/11] drm/i915: Infer vrefresh range for eDP if the EDID omits it Ville Syrjala
2022-08-29  8:56   ` Jani Nikula
2022-08-29 12:02   ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-08-26 22:35 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: Range descriptor stuff Patchwork
2022-08-26 23:03 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-08-29 14:36 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: Range descriptor stuff (rev2) Patchwork
2022-08-29 15:02 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-08-30 18:08 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/edid: Range descriptor stuff Patchwork
2022-08-31  5:36 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: Range descriptor stuff (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=YxIM2EmoMc1ElSCK@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox