From e29bb4ebbf000ff9ac081d29784a3331618f012e Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Fri, 20 Sep 2013 10:20:59 +0100 Subject: [PATCH 1/5] drm/i915: Use a temporary va_list for two-pass string handling In commit edc3d8848dc9fe2a470316363dab8ef211d77e01 Author: Mika Kuoppala Date: Thu May 23 13:55:35 2013 +0300 drm/i915: avoid big kmallocs on reading error state we introduce a two-pass mechanism for splitting long strings being formatted into the error-state. The first pass finds the length, and the second pass emits the right portion of the string into the accumulation buffer. Unfortunately we use the same va_list for both passes, resulting in the second pass reading garbage off the end of the argument list. As the two passes are only used for boundaries between read() calls, the corruption is only rarely seen. This fixes the root cause behind commit baf27f9b17bf2f369f3865e38c41d2163e8d815d Author: Chris Wilson Date: Sat Jun 29 23:26:50 2013 +0100 drm/i915: Break up the large vsnprintf() in print_error_buffers() Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Daniel Vetter Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gpu_error.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index aba9d7498996..dae364f0028c 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -143,8 +143,10 @@ static void i915_error_vprintf(struct drm_i915_error_state_buf *e, /* Seek the first printf which is hits start position */ if (e->pos < e->start) { - len = vsnprintf(NULL, 0, f, args); - if (!__i915_error_seek(e, len)) + va_list tmp; + + va_copy(tmp, args); + if (!__i915_error_seek(e, vsnprintf(NULL, 0, f, tmp))) return; } From 8d16f258217f2f583af1fd57c5144aa4bbe73e48 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Fri, 20 Sep 2013 16:42:15 +0300 Subject: [PATCH 2/5] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor Reviewed-by: Todd Previte Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 2151d13772b8..79c14e298ba6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -588,7 +588,18 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode, DRM_DEBUG_KMS("aux_ch native nack\n"); return -EREMOTEIO; case AUX_NATIVE_REPLY_DEFER: - udelay(100); + /* + * For now, just give more slack to branch devices. We + * could check the DPCD for I2C bit rate capabilities, + * and if available, adjust the interval. We could also + * be more careful with DP-to-Legacy adapters where a + * long legacy cable may force very low I2C bit rates. + */ + if (intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & + DP_DWN_STRM_PORT_PRESENT) + usleep_range(500, 600); + else + usleep_range(300, 400); continue; default: DRM_ERROR("aux_ch invalid native reply 0x%02x\n", From 1062b81598bc00e2f6620e6f3788f8f8df2f01e7 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 10 Sep 2013 11:44:30 +0200 Subject: [PATCH 3/5] drm/i915/tv: clear adjusted_mode.flags The native TV encoder has it's own flags to adjust sync modes and enabled interlaced modes which are totally irrelevant for the adjusted mode. This worked out nicely since the input modes used by both the load detect code and reported in the ->get_modes callbacks all have no flags set, and we also don't fill out any of them in the ->get_config callback. This changed with the additional sanitation done with commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 Author: Imre Deak Date: Tue Jul 30 13:36:32 2013 +0300 drm/i915: make user mode sync polarity setting explicit sinc now the "no flags at all" state wouldn't fit through core code any more. So fix this up again by explicitly clearing the flags in the ->compute_config callback. Aside: We have zero checking in place to make sure that the requested mode is indeed the right input mode we want for the selected TV mode. So we'll happily fall over if userspace tries to pull us. But that's definitely work for a different patch series. So just add a FIXME comment for now. Reported-by: Knut Petersen Cc: Knut Petersen Cc: Imre Deak Cc: Chris Wilson Tested-by: Knut Petersen Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_tv.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index f2c6d7909ae2..dd6f84bf6c22 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++ b/drivers/gpu/drm/i915/intel_tv.c @@ -916,6 +916,14 @@ intel_tv_compute_config(struct intel_encoder *encoder, DRM_DEBUG_KMS("forcing bpc to 8 for TV\n"); pipe_config->pipe_bpp = 8*3; + /* TV has it's own notion of sync and other mode flags, so clear them. */ + pipe_config->adjusted_mode.flags = 0; + + /* + * FIXME: We don't check whether the input mode is actually what we want + * or whether userspace is doing something stupid. + */ + return true; } From 67c72a12254101d4e8d9b9f3a02646ba0be84a2d Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 24 Sep 2013 11:46:14 +0200 Subject: [PATCH 4/5] drm/i915: preserve pipe A quirk in i9xx_set_pipeconf MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This regression has been introduced in commit 9f11a9e4e50006b615ba94722dfc33ced89664cf Author: Daniel Vetter Date: Thu Jun 13 00:54:58 2013 +0200 drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms Ville brough up the idea that this is just the pipe A quirk gone wrong. Note that after resume the bios might or might not have enabled pipe A already. We have a bit of magic to make sure that on resume we set up a decent mode for pipe A, but I fear if I just smash pipe A to always on we'd enable it in a bogus state and hang the hw. Hence the readback. v2: Clarify the logic a bit as suggested by Chris. Also amend the commit message to clarify why we don't unconditionally enable the pipe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462 References: https://lkml.org/lkml/2013/8/26/238 Cc: Meelis Roos Cc: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Chris Wilson [danvet: Use |= instead of = as suggested by Chris.] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d8a1d98693e7..e5822e79f912 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4775,6 +4775,10 @@ static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc) pipeconf = 0; + if (dev_priv->quirks & QUIRK_PIPEA_FORCE && + I915_READ(PIPECONF(intel_crtc->pipe)) & PIPECONF_ENABLE) + pipeconf |= PIPECONF_ENABLE; + if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) { /* Enable pixel doubling when the dot clock is > 90% of the (display) * core speed. From d32270460fee83e22ee9e6b1bfd7b486263eeb1d Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 25 Sep 2013 14:00:02 +0200 Subject: [PATCH 5/5] drm/i915: Fix up usage of SHRINK_STOP In commit 81e49f811404f428a9d9a63295a0c267e802fa12 Author: Glauber Costa Date: Wed Aug 28 10:18:13 2013 +1000 i915: bail out earlier when shrinker cannot acquire mutex SHRINK_STOP was added to tell the core shrinker code to bail out and go to the next shrinker since the i915 shrinker couldn't acquire required locks. But the SHRINK_STOP return code was added to the ->count_objects callback and not the ->scan_objects callback as it should have been, resulting in tons of dmesg noise like shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=-xxxxxxxxx Fix discusssed with Dave Chinner. References: http://www.spinics.net/lists/intel-gfx/msg33597.html Reported-by: Knut Petersen Cc: Knut Petersen Cc: Dave Chinner Cc: Glauber Costa Cc: Glauber Costa Cc: Andrew Morton Cc: Rik van Riel Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Acked-by: Dave Chinner Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index df9253d890ee..cdfb9da0e4ce 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4800,10 +4800,10 @@ i915_gem_inactive_count(struct shrinker *shrinker, struct shrink_control *sc) if (!mutex_trylock(&dev->struct_mutex)) { if (!mutex_is_locked_by(&dev->struct_mutex, current)) - return SHRINK_STOP; + return 0; if (dev_priv->mm.shrinker_no_lock_stealing) - return SHRINK_STOP; + return 0; unlock = false; } @@ -4901,10 +4901,10 @@ i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc) if (!mutex_trylock(&dev->struct_mutex)) { if (!mutex_is_locked_by(&dev->struct_mutex, current)) - return 0; + return SHRINK_STOP; if (dev_priv->mm.shrinker_no_lock_stealing) - return 0; + return SHRINK_STOP; unlock = false; }