From: Greg Kroah-Hartman Date: Thu, 9 May 2013 19:19:16 +0000 (-0700) Subject: 3.9-stable patches X-Git-Tag: v3.9.2~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6097cc339a6cfc09beff734f4f908f94de8c63e5;p=thirdparty%2Fkernel%2Fstable-queue.git 3.9-stable patches added patches: drm-i915-correct-the-calculation-of-first_pd_entry_in_global_pt.patch drm-i915-don-t-intel_crt_init-on-any-ult-machines.patch drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch drm-i915-fixup-oops-in-the-pipe-config-computation.patch --- diff --git a/queue-3.9/drm-i915-correct-the-calculation-of-first_pd_entry_in_global_pt.patch b/queue-3.9/drm-i915-correct-the-calculation-of-first_pd_entry_in_global_pt.patch new file mode 100644 index 00000000000..5e0b4d0707c --- /dev/null +++ b/queue-3.9/drm-i915-correct-the-calculation-of-first_pd_entry_in_global_pt.patch @@ -0,0 +1,48 @@ +From 43b27290dd42b40f3f23f49677a7faa5a4eb1eff Mon Sep 17 00:00:00 2001 +From: "Zhang, Xiong Y" +Date: Sat, 27 Apr 2013 09:53:33 +0000 +Subject: drm/i915: correct the calculation of first_pd_entry_in_global_pt + +From: "Zhang, Xiong Y" + +commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff upstream. + +When ppgtt is enabled, dev_priv->gtt.total has excluded the gtt space +occupied by ppgtt table in i915_gem_init_global_gtt() function. So the +calculation of first_pd_entry_in_global_pt doesn't need to subtract +I915_PPGTT_PD_ENTRIES again. Or else PPGTT directory table will be +destroyed by global gtt allocation. + +This regression has been introduced in + +commit a54c0c279f3864171fe53c66e769d5a137c5c651 +Author: Ben Widawsky +Date: Thu Jan 24 14:45:00 2013 -0800 + + drm/i915: remove intel_gtt structure + +The breakage is pretty subtile since the old gtt_total_entries +included the pde range, whereas the new on did not. + +Signed-off-by: Xiong Zhang +[danvet: Add regression citation and cc: stable. Thanks to Chris for +correcting my wrong guess about which commit broke things.] +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_gem_gtt.c ++++ b/drivers/gpu/drm/i915/i915_gem_gtt.c +@@ -182,8 +182,7 @@ static int gen6_ppgtt_init(struct i915_h + /* ppgtt PDEs reside in the global gtt pagetable, which has 512*1024 + * entries. For aliasing ppgtt support we just steal them at the end for + * now. */ +- first_pd_entry_in_global_pt = +- gtt_total_entries(dev_priv->gtt) - I915_PPGTT_PD_ENTRIES; ++ first_pd_entry_in_global_pt = gtt_total_entries(dev_priv->gtt); + + ppgtt->num_pd_entries = I915_PPGTT_PD_ENTRIES; + ppgtt->clear_range = gen6_ppgtt_clear_range; diff --git a/queue-3.9/drm-i915-don-t-intel_crt_init-on-any-ult-machines.patch b/queue-3.9/drm-i915-don-t-intel_crt_init-on-any-ult-machines.patch new file mode 100644 index 00000000000..2db0869ec9a --- /dev/null +++ b/queue-3.9/drm-i915-don-t-intel_crt_init-on-any-ult-machines.patch @@ -0,0 +1,32 @@ +From c40c0f5bd5b0f09e4386d2cf26c96c89c45ee539 Mon Sep 17 00:00:00 2001 +From: Paulo Zanoni +Date: Fri, 12 Apr 2013 18:16:53 -0300 +Subject: drm/i915: don't intel_crt_init on any ULT machines + +From: Paulo Zanoni + +commit c40c0f5bd5b0f09e4386d2cf26c96c89c45ee539 upstream. + +We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not +have CRT, so just check for !IS_ULT. This problem happened on a real +machine and resulted in a very ugly dmesg. + +Signed-off-by: Paulo Zanoni +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -8326,7 +8326,7 @@ static void intel_setup_outputs(struct d + I915_WRITE(PFIT_CONTROL, 0); + } + +- if (!(HAS_DDI(dev) && (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES))) ++ if (!IS_ULT(dev)) + intel_crt_init(dev); + + if (HAS_DDI(dev)) { diff --git a/queue-3.9/drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch b/queue-3.9/drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch new file mode 100644 index 00000000000..6b5479fc4c0 --- /dev/null +++ b/queue-3.9/drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch @@ -0,0 +1,55 @@ +From e4bfff54ed3f5de88f5358504c78c2cb037813aa Mon Sep 17 00:00:00 2001 +From: David Müller +Date: Fri, 19 Apr 2013 10:41:50 +0200 +Subject: drm/i915: Fall back to bit banging mode for DVO transmitter detection + +From: David Müller + +commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream. + +As discussed in this thread +http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html +GMBUS based DVO transmitter detection seems to be unreliable which could +result in an unusable DVO port. + +The attached patch fixes this by falling back to bit banging mode for +the time DVO transmitter detection is in progress. + +Signed-off-by: David Müller +Tested-by: David Müller +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_dvo.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_dvo.c ++++ b/drivers/gpu/drm/i915/intel_dvo.c +@@ -448,6 +448,7 @@ void intel_dvo_init(struct drm_device *d + const struct intel_dvo_device *dvo = &intel_dvo_devices[i]; + struct i2c_adapter *i2c; + int gpio; ++ bool dvoinit; + + /* Allow the I2C driver info to specify the GPIO to be used in + * special cases, but otherwise default to what's defined +@@ -467,7 +468,17 @@ void intel_dvo_init(struct drm_device *d + i2c = intel_gmbus_get_adapter(dev_priv, gpio); + + intel_dvo->dev = *dvo; +- if (!dvo->dev_ops->init(&intel_dvo->dev, i2c)) ++ ++ /* GMBUS NAK handling seems to be unstable, hence let the ++ * transmitter detection run in bit banging mode for now. ++ */ ++ intel_gmbus_force_bit(i2c, true); ++ ++ dvoinit = dvo->dev_ops->init(&intel_dvo->dev, i2c); ++ ++ intel_gmbus_force_bit(i2c, false); ++ ++ if (!dvoinit) + continue; + + intel_encoder->type = INTEL_OUTPUT_DVO; diff --git a/queue-3.9/drm-i915-fixup-oops-in-the-pipe-config-computation.patch b/queue-3.9/drm-i915-fixup-oops-in-the-pipe-config-computation.patch new file mode 100644 index 00000000000..3e378893b31 --- /dev/null +++ b/queue-3.9/drm-i915-fixup-oops-in-the-pipe-config-computation.patch @@ -0,0 +1,117 @@ +From b6c5164d7bf624f3e1b750787ddb983150c5117c Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Fri, 12 Apr 2013 18:48:43 +0200 +Subject: drm/i915: Fixup Oops in the pipe config computation + +From: Daniel Vetter + +commit b6c5164d7bf624f3e1b750787ddb983150c5117c upstream. + +Yet again our current confusion between doing the modeset globally, +but only having the new parameters for one crtc at a time. + +So that intel_set_mode essentially already does a global modeset: +intel_modeset_affected_pipes compares the current state with where we +want to go to (which is carefully set up by intel_crtc_set_config) and +then goes through the modeset sequence for any crtc which needs +updating. + +Now the issue is that the actual interface with the remaining code +still only works on one crtc, and so we only pass in one fb and one +mode. In intel_set_mode we also only compute one intel_crtc_config +(which should be the one for the crtc we're doing a modeset on). + +The reason for that mismatch is twofold: +- We want to eventually do all modeset as global state changes, so +it's just infrastructure prep. +- But even the old semantics can change more than one crtc when you +e.g. move a connector from crtc A to crtc B, then both crtc A and B +need to be updated. Usually that means one pipe is disabled and the +other enabled. This is also the reason why the hack doesn't touch the +disable_pipes mask. + +Now hilarity ensued in our kms config restore paths when we actually +try to do a modeset on all crtcs: If the first crtc should be off and +the second should be on, then the call on the first crtc will notice +that the 2nd one should be switched on and so tries to compute the +pipe_config. But due to a lack of passed-in fb (crtc 1 should be off +after all) it only results in tears. + +This case is ridiculously easy to hit on gen2/3 where the lvds output +is restricted to pipe B. Note that before the pipe_config bpp rework +gen2/3 didn't care really about the fb->depth, so this is a regression +brought to light with + +commit 4e53c2e010e531b4a014692199e978482d471c7e +Author: Daniel Vetter +Date: Wed Mar 27 00:44:58 2013 +0100 + + drm/i915: precompute pipe bpp before touching the hw + +But apparently Ajax also managed to blow up pch platforms, probably +with some randomized configs, and pch platforms trip up over the lack +of an fb even in the old code. So this actually goes back to the first +introduction of the new modeset restore code in + +commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 +Author: Daniel Vetter +Date: Fri Nov 23 18:16:34 2012 +0100 + + drm/i915: force restore on lid open + +Fix this mess by now by justing shunting all the cool new global +modeset logic in intel_modeset_affected_pipes. + +v2: Improve commit message and clean up all the comments in +intel_modeset_affected_pipes - since the introduction of the modeset +restore code they've been a bit outdated. + +Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 +References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html +Tested-by: Richard Cochran +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 23 +++++++++++++---------- + 1 file changed, 13 insertions(+), 10 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -7589,22 +7589,25 @@ intel_modeset_affected_pipes(struct drm_ + if (crtc->enabled) + *prepare_pipes |= 1 << intel_crtc->pipe; + +- /* We only support modeset on one single crtc, hence we need to do that +- * only for the passed in crtc iff we change anything else than just +- * disable crtcs. +- * +- * This is actually not true, to be fully compatible with the old crtc +- * helper we automatically disable _any_ output (i.e. doesn't need to be +- * connected to the crtc we're modesetting on) if it's disconnected. +- * Which is a rather nutty api (since changed the output configuration +- * without userspace's explicit request can lead to confusion), but +- * alas. Hence we currently need to modeset on all pipes we prepare. */ ++ /* ++ * For simplicity do a full modeset on any pipe where the output routing ++ * changed. We could be more clever, but that would require us to be ++ * more careful with calling the relevant encoder->mode_set functions. ++ */ + if (*prepare_pipes) + *modeset_pipes = *prepare_pipes; + + /* ... and mask these out. */ + *modeset_pipes &= ~(*disable_pipes); + *prepare_pipes &= ~(*disable_pipes); ++ ++ /* ++ * HACK: We don't (yet) fully support global modesets. intel_set_config ++ * obies this rule, but the modeset restore mode of ++ * intel_modeset_setup_hw_state does not. ++ */ ++ *modeset_pipes &= 1 << intel_crtc->pipe; ++ *prepare_pipes &= 1 << intel_crtc->pipe; + } + + static bool intel_crtc_in_use(struct drm_crtc *crtc) diff --git a/queue-3.9/series b/queue-3.9/series index f42addf8b40..9cea5d84f93 100644 --- a/queue-3.9/series +++ b/queue-3.9/series @@ -37,3 +37,7 @@ drm-i915-use-mlc-l3-for-context-objects.patch drm-i915-set-cpt-fdi-rx-polarity-bits-based-on-vbt.patch drm-i915-don-t-check-inconsistent-modeset-state-when-force-restoring.patch drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch +drm-i915-don-t-intel_crt_init-on-any-ult-machines.patch +drm-i915-fixup-oops-in-the-pipe-config-computation.patch +drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch +drm-i915-correct-the-calculation-of-first_pd_entry_in_global_pt.patch