--- /dev/null
+From 34dc8993eef63681b062871413a9484008a2a78f Mon Sep 17 00:00:00 2001
+From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+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 <mika.kuoppala@linux.intel.com>
+
+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 <chris@chris-wilson.co.uk>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Len Brown <len.brown@intel.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: fritsch@xbmc.org
+Cc: miku@iki.fi
+Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
+CC: Michal Feix <michal@feix.cz>
+Cc: Hans de Goede <hdegoede@redhat.com>
+Cc: Deepak S <deepak.s@linux.intel.com>
+Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
+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 <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From d253371c4c2f5fc2d884ef25f64decd7549aff5a Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+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 <imre.deak@intel.com>
+
+commit d253371c4c2f5fc2d884ef25f64decd7549aff5a upstream.
+
+After
+commit 2c7d0602c815277f7cb7c932b091288710d8aba7
+Author: Imre Deak <imre.deak@intel.com>
+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ä <ville.syrjala@linux.intel.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
+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 <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From edd06b8353772dca7afcd4640dafa83b521edd55 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+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ä <ville.syrjala@linux.intel.com>
+
+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 <maarten.lankhorst@linux.intel.com>
+Fixes: bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.com
+Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+(cherry picked from commit c3f8ad57a01a31397e5a0349a226a32f35ddc19c)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
