From: Greg Kroah-Hartman Date: Thu, 9 May 2013 19:19:12 +0000 (-0700) Subject: 3.8-stable patches X-Git-Tag: v3.9.2~39 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=21afeebd905ba1306428c7335cf5030bcd517749;p=thirdparty%2Fkernel%2Fstable-queue.git 3.8-stable patches added patches: 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.8/drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch b/queue-3.8/drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch index 96969a2c6b0..61b167788da 100644 --- a/queue-3.8/drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch +++ b/queue-3.8/drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch @@ -32,7 +32,7 @@ Signed-off-by: Greg Kroah-Hartman --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c -@@ -9256,6 +9256,9 @@ void intel_modeset_cleanup(struct drm_de +@@ -9388,6 +9388,9 @@ void intel_modeset_cleanup(struct drm_de /* flush any delayed tasks or pending work */ flush_scheduled_work(); @@ -40,11 +40,11 @@ Signed-off-by: Greg Kroah-Hartman + intel_panel_destroy_backlight(dev); + drm_mode_config_cleanup(dev); + } - intel_cleanup_overlay(dev); --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c -@@ -2538,17 +2538,14 @@ done: +@@ -2467,17 +2467,14 @@ done: static void intel_dp_destroy(struct drm_connector *connector) { @@ -65,7 +65,7 @@ Signed-off-by: Greg Kroah-Hartman drm_connector_cleanup(connector); --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c -@@ -618,7 +618,6 @@ static void intel_lvds_destroy(struct dr +@@ -556,7 +556,6 @@ static void intel_lvds_destroy(struct dr if (!IS_ERR_OR_NULL(lvds_connector->base.edid)) kfree(lvds_connector->base.edid); diff --git a/queue-3.8/drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch b/queue-3.8/drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch new file mode 100644 index 00000000000..70544da7d9a --- /dev/null +++ b/queue-3.8/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 +@@ -449,6 +449,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 +@@ -468,7 +469,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.8/drm-i915-fixup-oops-in-the-pipe-config-computation.patch b/queue-3.8/drm-i915-fixup-oops-in-the-pipe-config-computation.patch new file mode 100644 index 00000000000..69184f66cea --- /dev/null +++ b/queue-3.8/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 +@@ -7732,22 +7732,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.8/series b/queue-3.8/series index c46dbf90cfa..73a382b0faa 100644 --- a/queue-3.8/series +++ b/queue-3.8/series @@ -41,3 +41,5 @@ drm-i915-workaround-incoherence-between-fences-and-llc-across-multiple-cpus.patc drm-i915-use-mlc-l3-for-context-objects.patch drm-i915-set-cpt-fdi-rx-polarity-bits-based-on-vbt.patch drm-i915-ensure-single-initialization-and-cleanup-of-backlight-device.patch +drm-i915-fixup-oops-in-the-pipe-config-computation.patch +drm-i915-fall-back-to-bit-banging-mode-for-dvo-transmitter-detection.patch