[Bug 103549] [HSW] Linux 4.13 CTS regressions
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Nov 3 02:18:22 UTC 2017
https://bugs.freedesktop.org/show_bug.cgi?id=103549
--- Comment #1 from Chris Wilson <chris at chris-wilson.co.uk> ---
In the unexpected bisect of the day:
b7048ea12fbb2724ee0cd30752d4fac43cab0651 is the first bad commit
commit b7048ea12fbb2724ee0cd30752d4fac43cab0651
Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
Date: Wed Mar 15 16:31:58 2017 +0200
drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks
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.
Cc: stable at vger.kernel.org
Cc: Gabriele Mazzotta <gabriele.mzt at gmail.com>
Cc: David Purton <dcpurton at marshwiggle.net>
Cc: Matt Roper <matthew.d.roper at intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
Reported-by: Gabriele Mazzotta <gabriele.mzt at gmail.com>
Reported-by: David Purton <dcpurton at marshwiggle.net>
Tested-by: Gabriele Mazzotta <gabriele.mzt at gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645
Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark
programming (v11)")
Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
Link:
http://patchwork.freedesktop.org/patch/msgid/20170220140443.30891-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Link:
http://patchwork.freedesktop.org/patch/msgid/20170315143158.31780-1-ville.syrjala@linux.intel.com
(cherry picked from commit 5be6e33400992d3450e1c8234a5af353e1560580)
Signed-off-by: Jani Nikula <jani.nikula at intel.com>
So it looks like some of those registers are now stored in the power context,
thus loading them before rc6 is held to wake up GT means the settings are lost.
Quick fix:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 91bc4ab..f1e03e6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1244,6 +1244,52 @@ static int init_render_ring(struct intel_engine_cs
*engine)
if (IS_GEN(dev_priv, 6, 7))
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
+
+ if (IS_HASWELL(dev_priv)) {
+ /* L3 caching of data atomics doesn't work -- disable it. */
+ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+ I915_WRITE(HSW_ROW_CHICKEN3,
+
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
+
+ /* This is required by WaCatErrorRejectionIssue:hsw */
+ I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
+ I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
+ GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
+
+ /* WaVSRefCountFullforceMissDisable:hsw */
+ I915_WRITE(GEN7_FF_THREAD_MODE,
+ I915_READ(GEN7_FF_THREAD_MODE) &
~GEN7_FF_VS_REF_CNT_FFME);
+
+ /* WaDisable_RenderCache_OperationalFlush:hsw */
+ I915_WRITE(CACHE_MODE_0_GEN7,
_MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
+
+ /* enable HiZ Raw Stall Optimization */
+ I915_WRITE(CACHE_MODE_0_GEN7,
+
_MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
+
+ /* WaDisable4x2SubspanOptimization:hsw */
+ I915_WRITE(CACHE_MODE_1,
+
_MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE));
+
+ /*
+ * BSpec recommends 8x4 when MSAA is used,
+ * however in practice 16x4 seems fastest.
+ *
+ * Note that PS/WM thread counts depend on the WIZ hashing
+ * disable bit, which we don't touch here, but it's good
+ * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+ */
+ I915_WRITE(GEN7_GT_MODE,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK,
GEN6_WIZ_HASHING_16x4));
+
+ /* WaSampleCChickenBitEnable:hsw */
+ I915_WRITE(HALF_SLICE_CHICKEN3,
+ _MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE));
+
+ /* WaSwitchSolVfFArbitrationPriority:hsw */
+ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
HSW_ECOCHK_ARB_PRIO_SOL);
+ }
+
if (INTEL_INFO(dev_priv)->gen >= 6)
I915_WRITE_IMR(engine, ~engine->irq_keep_mask);
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20171103/806d4862/attachment-0001.html>
More information about the intel-gfx-bugs
mailing list