Patch "drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks" has been added to the 4.10-stable tree

This is a note to let you know that I've just added the patch titled

drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks

to the 4.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch
and it can be found in the queue-4.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <[email protected]>
Date: Wed, 15 Mar 2017 16:31:58 +0200
Subject: drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Ville Syrjälä <[email protected]>

commit b7048ea12fbb2724ee0cd30752d4fac43cab0651 upstream.

Currently ILK-BDW explicitly disable LP1+ watermarks from their .init_clock_gating() hooks. Unfortunately that hook gets called way too late since by that time we've already initialized all the watermark state tracking which then gets out of sync with the hardware state.

We may eventually want to consider killing off the explicit LP1+ disable from .init_clock_gating(). In the meantime however, we can avoid the problem by reordering the init sequence such that intel_modeset_init_hw()->intel_init_clock_gating() gets called prior to the hardware state takeover.

I suppose prior to the two stage watermark programming we were magically saved by something that forced the watermarks to be reprogrammed fully after .init_clock_gating() got called. But now that no longer happens.

Note that the diff might look a bit odd as it kills off one call of intel_update_cdclk(), but that's fine because intel_modeset_init_hw() does the exact same thing. Previously we just did it twice.

Actually even this new init sequence is pretty bogus as .init_clock_gating() really should be called before any gem hardware init since it can configure various clock gating workarounds and whatnot that affect the GT side as well. Also intel_modeset_init() really should get split up into better defined init stages. Another "fun" detail is that intel_modeset_gem_init() is where RPS/RC6 gets configured. Why that is done from the display code is beyond me. I've decided to leave all this be for now, and just try to fix the init sequence enough for watermarks to work.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645

---
 drivers/gpu/drm/i915/intel_display.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

@@ -16489,12 +16489,11 @@ int intel_modeset_init(struct drm_device
 		}
 	}
 
-	intel_update_czclk(dev_priv);
-	intel_update_cdclk(dev_priv);
-	dev_priv->atomic_cdclk_freq = dev_priv->cdclk_freq;
-
 	intel_shared_dpll_init(dev);
 
+	intel_update_czclk(dev_priv);
+	intel_modeset_init_hw(dev);
+
 	if (dev_priv->max_cdclk_freq == 0)
 		intel_update_max_cdclk(dev_priv);
 

@@ -17049,8 +17048,6 @@ void intel_modeset_gem_init(struct drm_d
 
 	intel_init_gt_powersave(dev_priv);
 
-	intel_modeset_init_hw(dev);
-
 	intel_setup_overlay(dev_priv);
 }
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.10/drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch queue-4.10/drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch queue-4.10/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch queue-4.10/drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch queue-4.10/drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch queue-4.10/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch queue-4.10/drm-i915-move-updating-color-management-to-before-vblank-evasion.patch