From: Greg Kroah-Hartman Date: Wed, 12 Apr 2017 12:50:13 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.10.11~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=526d5907c8e5ca2aae00841b0a933781ec521831;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch --- diff --git a/queue-4.4/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch b/queue-4.4/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch new file mode 100644 index 00000000000..9c3e59e7357 --- /dev/null +++ b/queue-4.4/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch @@ -0,0 +1,95 @@ +From 34dc8993eef63681b062871413a9484008a2a78f Mon Sep 17 00:00:00 2001 +From: Mika Kuoppala +Date: Wed, 15 Feb 2017 15:52:59 +0200 +Subject: drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mika Kuoppala + +commit 34dc8993eef63681b062871413a9484008a2a78f upstream. + +Certain Baytrails, namely the 4 cpu core variants, have been +plaqued by spurious system hangs, mostly occurring with light loads. + +Multiple bisects by various people point to a commit which changes the +reclocking strategy for Baytrail to follow its bigger brethen: +commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") + +There is also a review comment attached to this commit from Deepak S +on avoiding punit access on Cherryview and thus it was excluded on +common reclocking path. By taking the same approach and omitting +the punit access by not tweaking the thresholds when the hardware +has been asked to move into different frequency, considerable gains +in stability have been observed. + +With J1900 box, light render/video load would end up in system hang +in usually less than 12 hours. With this patch applied, the cumulative +uptime has now been 34 days without issues. To provoke system hang, +light loads on both render and bsd engines in parallel have been used: +glxgears >/dev/null 2>/dev/null & +mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4 + +So far, author has not witnessed system hang with above load +and this patch applied. Reports from the tenacious people at +kernel bugzilla are also promising. + +Considering that the punit access frequency with this patch is +considerably less, there is a possibility that this will push +the, still unknown, root cause past the triggering point on most loads. + +But as we now can reliably reproduce the hang independently, +we can reduce the pain that users are having and use a +static thresholds until a root cause is found. + +v3: don't break debugfs and simplification (Chris Wilson) + +References: https://bugzilla.kernel.org/show_bug.cgi?id=109051 +Cc: Chris Wilson +Cc: Ville Syrjälä +Cc: Len Brown +Cc: Daniel Vetter +Cc: Jani Nikula +Cc: fritsch@xbmc.org +Cc: miku@iki.fi +Cc: Ezequiel Garcia +CC: Michal Feix +Cc: Hans de Goede +Cc: Deepak S +Cc: Jarkko Nikula +Acked-by: Daniel Vetter +Acked-by: Chris Wilson +Signed-off-by: Mika Kuoppala +Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com +(cherry picked from commit 6067a27d1f0184596d51decbac1c1fdc4acb012f) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_pm.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4376,6 +4376,12 @@ static void gen6_set_rps_thresholds(stru + break; + } + ++ /* When byt can survive without system hang with dynamic ++ * sw freq adjustments, this restriction can be lifted. ++ */ ++ if (IS_VALLEYVIEW(dev_priv)) ++ goto skip_hw_write; ++ + I915_WRITE(GEN6_RP_UP_EI, + GT_INTERVAL_FROM_US(dev_priv, ei_up)); + I915_WRITE(GEN6_RP_UP_THRESHOLD, +@@ -4394,6 +4400,7 @@ static void gen6_set_rps_thresholds(stru + GEN6_RP_UP_BUSY_AVG | + GEN6_RP_DOWN_IDLE_AVG); + ++skip_hw_write: + dev_priv->rps.power = new_power; + dev_priv->rps.up_threshold = threshold_up; + dev_priv->rps.down_threshold = threshold_down;