From: Greg Kroah-Hartman Date: Tue, 24 Apr 2018 16:31:19 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.16.5~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9612ed317e6c1e1741727286c47c8add3d735fca;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-i915-bxt-glk-increase-pcode-timeouts-during-cdclk-freq-changing.patch --- diff --git a/queue-4.9/drm-i915-bxt-glk-increase-pcode-timeouts-during-cdclk-freq-changing.patch b/queue-4.9/drm-i915-bxt-glk-increase-pcode-timeouts-during-cdclk-freq-changing.patch new file mode 100644 index 00000000000..b4185efdf5f --- /dev/null +++ b/queue-4.9/drm-i915-bxt-glk-increase-pcode-timeouts-during-cdclk-freq-changing.patch @@ -0,0 +1,115 @@ +From 5e1df40f40ee45a97bb1066c3d71f0ae920a9672 Mon Sep 17 00:00:00 2001 +From: Imre Deak +Date: Tue, 30 Jan 2018 16:29:38 +0200 +Subject: drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Imre Deak + +commit 5e1df40f40ee45a97bb1066c3d71f0ae920a9672 upstream. + +Currently we see sporadic timeouts during CDCLK changing both on BXT and +GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by +changing the frequency in a tight loop after blanking the display. The +upper bound for the completion time is 800us based on my tests, so +increase it from the current 500us to 2ms; with that I couldn't trigger +the problem either on BXT or GLK. + +Note that timeouts happened during both the change notification and the +voltage level setting PCODE request. (For the latter one BSpec doesn't +require us to wait for completion before further HW programming.) + +This issue is similar to +commit 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK +change notification") +but there the PCODE request does complete (as shown by the mbox +busy flag), only the reply we get from PCODE indicates a failure. +So there we keep resending the request until a success reply, here we +just have to increase the timeout for the one PCODE request we send. + +v2: +- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville) + +Cc: Chris Wilson +Cc: Ville Syrjälä +Cc: # v4.9 +Acked-by: Chris Wilson (v1) +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326 +Reviewed-by: Ville Syrjälä +Signed-off-by: Imre Deak +Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com +(cherry picked from commit e76019a81921e87a4d9e7b3d86102bc708a6c227) +Signed-off-by: Rodrigo Vivi +(Rebased for v4.9 stable tree due to upstream intel_cdclk.c, cdclk_state and pcu_lock change) +Signed-off-by: Imre Deak +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/i915_drv.h | 6 +++++- + drivers/gpu/drm/i915/intel_display.c | 9 +++++---- + drivers/gpu/drm/i915/intel_pm.c | 6 +++--- + 3 files changed, 13 insertions(+), 8 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -3681,7 +3681,11 @@ extern void intel_display_print_error_st + struct intel_display_error_state *error); + + int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 *val); +-int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32 val); ++int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, u32 mbox, ++ u32 val, int timeout_us); ++#define sandybridge_pcode_write(dev_priv, mbox, val) \ ++ sandybridge_pcode_write_timeout(dev_priv, mbox, val, 500) ++ + int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request, + u32 reply_mask, u32 reply, int timeout_base_ms); + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -6012,8 +6012,8 @@ static void bxt_set_cdclk(struct drm_i91 + + /* Inform power controller of upcoming frequency change */ + mutex_lock(&dev_priv->rps.hw_lock); +- ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, +- 0x80000000); ++ ret = sandybridge_pcode_write_timeout(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, ++ 0x80000000, 2000); + mutex_unlock(&dev_priv->rps.hw_lock); + + if (ret) { +@@ -6044,8 +6044,9 @@ static void bxt_set_cdclk(struct drm_i91 + I915_WRITE(CDCLK_CTL, val); + + mutex_lock(&dev_priv->rps.hw_lock); +- ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, +- DIV_ROUND_UP(cdclk, 25000)); ++ ret = sandybridge_pcode_write_timeout(dev_priv, ++ HSW_PCODE_DE_WRITE_FREQ_REQ, ++ DIV_ROUND_UP(cdclk, 25000), 2000); + mutex_unlock(&dev_priv->rps.hw_lock); + + if (ret) { +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -7913,8 +7913,8 @@ int sandybridge_pcode_read(struct drm_i9 + return 0; + } + +-int sandybridge_pcode_write(struct drm_i915_private *dev_priv, +- u32 mbox, u32 val) ++int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, ++ u32 mbox, u32 val, int timeout_us) + { + int status; + +@@ -7935,7 +7935,7 @@ int sandybridge_pcode_write(struct drm_i + + if (intel_wait_for_register_fw(dev_priv, + GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0, +- 500)) { ++ timeout_us)) { + DRM_ERROR("timeout waiting for pcode write (%d) to finish\n", mbox); + return -ETIMEDOUT; + } diff --git a/queue-4.9/series b/queue-4.9/series index 6ae272beff7..2e6491c1e78 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -13,3 +13,4 @@ revert-perf-tools-decompress-kernel-module-when-reading-dso.patch perf-fix-sample_max_stack-maximum-check.patch perf-return-proper-values-for-user-stack-errors.patch rdma-mlx5-fix-null-dereference-while-accessing-xrc_tgt-qps.patch +drm-i915-bxt-glk-increase-pcode-timeouts-during-cdclk-freq-changing.patch