public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings
Date: Sat, 27 Aug 2022 00:34:58 +0300	[thread overview]
Message-ID: <20220826213501.31490-9-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20220826213501.31490-1-ville.syrjala@linux.intel.com>

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);
+
+		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;
 }
 
 /*
-- 
2.35.1


  parent reply	other threads:[~2022-08-26 21:36 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 ` Ville Syrjala [this message]
2022-09-02 13:41   ` [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings Jani Nikula
2022-09-02 14:02     ` Ville Syrjälä
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=20220826213501.31490-9-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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