Attachment 144504 Details for Bug 110782 – [PATCH] drm/i915: Don't clobber M/N values during fastset check

[patch] [PATCH] drm/i915: Don't clobber M/N values during fastset check

0001-drm-i915-Don-t-clobber-M-N-values-during-fastset-che.patch (text/plain), 3.20 KB, created by Ville Syrjala on 2019-06-11 15:18:07 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ville Syrjala

Created: 2019-06-11 15:18:07 UTC

Size: 3.20 KB

patch

obsolete

>From ebca380060349e423c41486e388b9a53e3a5e1bd Mon Sep 17 00:00:00 2001
>From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
>Date: Tue, 11 Jun 2019 17:22:43 +0300
>Subject: [PATCH] drm/i915: Don't clobber M/N values during fastset check
>MIME-Version: 1.0
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>We're now calling intel_pipe_config_compare(..., true) uncoditionally
>which means we're always going clobber the calculated M/N values with
>the old values if the fuzzy M/N check passes. That causes problems
>because the fuzzy check allows for a huge difference in the values.
>
>I'm actually tempted to just make the M/N checks exact, but that might
>prevent fastboot from kicking in when people want it. So for now let's
>overwrite the computed values with the old values only if decide to skip
>the modeset.
>
>Cc: stable@vger.kernel.org
>Cc: Blubberbub@protonmail.com
>Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Cc: Hans de Goede <hdegoede@redhat.com>
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110782
>Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
>Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>---
> drivers/gpu/drm/i915/intel_display.c | 35 +++++++++++++++++++++-------
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>index 62fa573f90e8..13b347a575a8 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -12226,9 +12226,6 @@ intel_compare_link_m_n(const struct intel_link_m_n *m_n,
> 			      m2_n2->gmch_m, m2_n2->gmch_n, !adjust) &&
> 	    intel_compare_m_n(m_n->link_m, m_n->link_n,
> 			      m2_n2->link_m, m2_n2->link_n, !adjust)) {
>-		if (adjust)
>-			*m2_n2 = *m_n;
>-
> 		return true;
> 	}
> 
>@@ -13360,6 +13357,32 @@ static int calc_watermark_data(struct intel_atomic_state *state)
> 	return 0;
> }
> 
>+static void intel_crtc_check_fastset(struct intel_crtc_state *old_crtc_state,
>+				     struct intel_crtc_state *new_crtc_state)
>+{
>+	struct drm_i915_private *dev_priv =
>+		to_i915(new_crtc_state->base.crtc->dev);
>+
>+	if (!intel_pipe_config_compare(dev_priv, old_crtc_state,
>+				       new_crtc_state, true))
>+		return;
>+
>+	new_crtc_state->base.mode_changed = false;
>+	new_crtc_state->update_pipe = true;
>+
>+	/*
>+	 * If we're not doing the full modeset we want to
>+	 * keep the current M/N values as they may be
>+	 * sufficiently different to the computed values
>+	 * to cause problems.
>+	 *
>+	 * FIXME: should really copy more fuzzy state here
>+	 */
>+	new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
>+	new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
>+	new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
>+}
>+
> /**
>  * intel_atomic_check - validate state object
>  * @dev: drm device
>@@ -13401,11 +13424,7 @@ static int intel_atomic_check(struct drm_device *dev,
> 		if (ret)
> 			goto fail;
> 
>-		if (intel_pipe_config_compare(dev_priv, old_crtc_state,
>-					      new_crtc_state, true)) {
>-			new_crtc_state->base.mode_changed = false;
>-			new_crtc_state->update_pipe = true;
>-		}
>+		intel_crtc_check_fastset(old_crtc_state, new_crtc_state);
> 
> 		if (needs_modeset(&new_crtc_state->base))
> 			any_ms = true;
>-- 
>2.21.0
>

Actions: View | Splinter Review

Attachments on bug 110782: 144368 | 144369 | 144424 | 144473 | 144474 | 144475 | 144494 | 144499 | 144504

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.