--- /dev/null
+From 43b27290dd42b40f3f23f49677a7faa5a4eb1eff Mon Sep 17 00:00:00 2001
+From: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
+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" <xiong.y.zhang@intel.com>
+
+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 <ben@bwidawsk.net>
+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<xiong.y.zhang@intel.com>
+[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 <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From c40c0f5bd5b0f09e4386d2cf26c96c89c45ee539 Mon Sep 17 00:00:00 2001
+From: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Date: Fri, 12 Apr 2013 18:16:53 -0300
+Subject: drm/i915: don't intel_crt_init on any ULT machines
+
+From: Paulo Zanoni <paulo.r.zanoni@intel.com>
+
+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 <paulo.r.zanoni@intel.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)) {
--- /dev/null
+From e4bfff54ed3f5de88f5358504c78c2cb037813aa Mon Sep 17 00:00:00 2001
+From: David Müller <d.mueller@elsoft.ch>
+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 <d.mueller@elsoft.ch>
+
+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 <d.mueller@elsoft.ch>
+Tested-by: David Müller <d.mueller@elsoft.ch>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b6c5164d7bf624f3e1b750787ddb983150c5117c Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Fri, 12 Apr 2013 18:48:43 +0200
+Subject: drm/i915: Fixup Oops in the pipe config computation
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+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 <daniel.vetter@ffwll.ch>
+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 <daniel.vetter@ffwll.ch>
+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 <richardcochran@gmail.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
