From: Greg Kroah-Hartman Date: Wed, 12 Apr 2017 12:50:34 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.10.11~23 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ffe3588f9f8b80ca365b810f904a25d0a2a99f38;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch --- diff --git a/queue-4.9/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch b/queue-4.9/drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch new file mode 100644 index 00000000000..3cbbc6a4750 --- /dev/null +++ b/queue-4.9/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 +@@ -4903,6 +4903,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, +@@ -4923,6 +4929,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; diff --git a/queue-4.9/drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch b/queue-4.9/drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch new file mode 100644 index 00000000000..9210fd62234 --- /dev/null +++ b/queue-4.9/drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch @@ -0,0 +1,76 @@ +From d253371c4c2f5fc2d884ef25f64decd7549aff5a Mon Sep 17 00:00:00 2001 +From: Imre Deak +Date: Fri, 24 Feb 2017 16:32:10 +0200 +Subject: drm/i915/gen9: Increase PCODE request timeout to 50ms +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Imre Deak + +commit d253371c4c2f5fc2d884ef25f64decd7549aff5a upstream. + +After +commit 2c7d0602c815277f7cb7c932b091288710d8aba7 +Author: Imre Deak +Date: Mon Dec 5 18:27:37 2016 +0200 + + drm/i915/gen9: Fix PCODE polling during CDCLK change notification + +there is still one report of the CDCLK-change request timing out on a +KBL machine, see the Reference link. On that machine the maximum time +the request took to succeed was 34ms, so increase the timeout to 50ms. + +v2: +- Change timeout from 100 to 50 ms to maintain the current 50 ms limit + for atomic waits in the driver. (Chris, Tvrtko) + +Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345 +Cc: Ville Syrjälä +Cc: Chris Wilson +Cc: Tvrtko Ursulin +Signed-off-by: Imre Deak +Acked-by: Chris Wilson +Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com +(cherry picked from commit 0129936ddda26afd5d9d207c4e86b2425952579f) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_pm.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -7960,10 +7960,10 @@ static bool skl_pcode_try_request(struct + * @timeout_base_ms: timeout for polling with preemption enabled + * + * Keep resending the @request to @mbox until PCODE acknowledges it, PCODE +- * reports an error or an overall timeout of @timeout_base_ms+10 ms expires. ++ * reports an error or an overall timeout of @timeout_base_ms+50 ms expires. + * The request is acknowledged once the PCODE reply dword equals @reply after + * applying @reply_mask. Polling is first attempted with preemption enabled +- * for @timeout_base_ms and if this times out for another 10 ms with ++ * for @timeout_base_ms and if this times out for another 50 ms with + * preemption disabled. + * + * Returns 0 on success, %-ETIMEDOUT in case of a timeout, <0 in case of some +@@ -7999,14 +7999,15 @@ int skl_pcode_request(struct drm_i915_pr + * worst case) _and_ PCODE was busy for some reason even after a + * (queued) request and @timeout_base_ms delay. As a workaround retry + * the poll with preemption disabled to maximize the number of +- * requests. Increase the timeout from @timeout_base_ms to 10ms to ++ * requests. Increase the timeout from @timeout_base_ms to 50ms to + * account for interrupts that could reduce the number of these +- * requests. ++ * requests, and for any quirks of the PCODE firmware that delays ++ * the request completion. + */ + DRM_DEBUG_KMS("PCODE timeout, retrying with preemption disabled\n"); + WARN_ON_ONCE(timeout_base_ms > 3); + preempt_disable(); +- ret = wait_for_atomic(COND, 10); ++ ret = wait_for_atomic(COND, 50); + preempt_enable(); + + out: diff --git a/queue-4.9/drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch b/queue-4.9/drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch new file mode 100644 index 00000000000..04a766a185c --- /dev/null +++ b/queue-4.9/drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch @@ -0,0 +1,73 @@ +From edd06b8353772dca7afcd4640dafa83b521edd55 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Tue, 7 Mar 2017 22:54:19 +0200 +Subject: drm/i915: Nuke debug messages from the pipe update critical section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit edd06b8353772dca7afcd4640dafa83b521edd55 upstream. + +printks are slow so we should not be doing them from the vblank evade +critical section. These could explain why we sometimes seem to +blow past our 100 usec deadline. + +The problem has been there ever since commit bfd16b2a23dc ("drm/i915: +Make updating pipe without modeset atomic.") but it may not have +been readily visible until commit e1edbd44e23b ("drm/i915: Complain +if we take too long under vblank evasion.") increased our chances +of noticing it. + +Cc: Maarten Lankhorst +Fixes: bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.") +Signed-off-by: Ville Syrjälä +Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.com +Reviewed-by: Maarten Lankhorst +(cherry picked from commit c3f8ad57a01a31397e5a0349a226a32f35ddc19c) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 12 +----------- + 1 file changed, 1 insertion(+), 11 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -3696,10 +3696,6 @@ static void intel_update_pipe_config(str + /* drm_atomic_helper_update_legacy_modeset_state might not be called. */ + crtc->base.mode = crtc->base.state->mode; + +- DRM_DEBUG_KMS("Updating pipe size %ix%i -> %ix%i\n", +- old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h, +- pipe_config->pipe_src_w, pipe_config->pipe_src_h); +- + /* + * Update pipe size and adjust fitter if needed: the reason for this is + * that in compute_mode_changes we check the native mode (not the pfit +@@ -4832,23 +4828,17 @@ static void skylake_pfit_enable(struct i + struct intel_crtc_scaler_state *scaler_state = + &crtc->config->scaler_state; + +- DRM_DEBUG_KMS("for crtc_state = %p\n", crtc->config); +- + if (crtc->config->pch_pfit.enabled) { + int id; + +- if (WARN_ON(crtc->config->scaler_state.scaler_id < 0)) { +- DRM_ERROR("Requesting pfit without getting a scaler first\n"); ++ if (WARN_ON(crtc->config->scaler_state.scaler_id < 0)) + return; +- } + + id = scaler_state->scaler_id; + I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN | + PS_FILTER_MEDIUM | scaler_state->scalers[id].mode); + I915_WRITE(SKL_PS_WIN_POS(pipe, id), crtc->config->pch_pfit.pos); + I915_WRITE(SKL_PS_WIN_SZ(pipe, id), crtc->config->pch_pfit.size); +- +- DRM_DEBUG_KMS("for crtc_state = %p scaler_id = %d\n", crtc->config, id); + } + } +