--- /dev/null
+From d472fcc8379c062bd56a3876fc6ef22258f14a91 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 24 Nov 2014 11:12:42 +0100
+Subject: drm/i915: Disallow pin ioctl completely for kms drivers
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit d472fcc8379c062bd56a3876fc6ef22258f14a91 upstream.
+
+The problem here is that SNA pins batchbuffers to etch out a bit more
+performance. Iirc it started out as a w/a for i830M (which we've
+implemented in the kernel since a long time already). The problem is
+that the pin ioctl wasn't added in
+
+commit d23db88c3ab233daed18709e3a24d6c95344117f
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri May 23 08:48:08 2014 +0200
+
+ drm/i915: Prevent negative relocation deltas from wrapping
+
+Fix this by simply disallowing pinning from userspace so that the
+kernel is in full control of batch placement again. Especially since
+distros are moving towards running X as non-root, so most users won't
+even be able to see any benefits.
+
+UMS support is dead now, but we need this minimal patch for
+backporting. Follow-up patch will remove the pin ioctl code
+completely.
+
+Note to backporters: You must have both
+
+commit b45305fce5bb1abec263fcff9d81ebecd6306ede
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon Dec 17 16:21:27 2012 +0100
+
+ drm/i915: Implement workaround for broken CS tlb on i830/845
+
+which laned in 3.8 and
+
+commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Mon Sep 8 14:25:41 2014 +0100
+
+ drm/i915: Evict CS TLBs between batches
+
+which is also marked cc: stable. Otherwise this could introduce a
+regression by disabling the userspace w/a without the kernel w/a being
+fully functional on i830/45.
+
+References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -4193,7 +4193,7 @@ i915_gem_pin_ioctl(struct drm_device *de
+ struct drm_i915_gem_object *obj;
+ int ret;
+
+- if (INTEL_INFO(dev)->gen >= 6)
++ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -ENODEV;
+
+ ret = i915_mutex_lock_interruptible(dev);
+@@ -4249,6 +4249,9 @@ i915_gem_unpin_ioctl(struct drm_device *
+ struct drm_i915_gem_object *obj;
+ int ret;
+
++ if (drm_core_check_feature(dev, DRIVER_MODESET))
++ return -ENODEV;
++
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ret;
--- /dev/null
+From 0b6d24c01932db99fc95304235e751e7f7625c41 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Fri, 11 Apr 2014 15:55:17 +0200
+Subject: drm/i915: Don't complain about stolen conflicts on gen3
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 0b6d24c01932db99fc95304235e751e7f7625c41 upstream.
+
+Apparently stuff works that way on those machines.
+
+I agree with Chris' concern that this is a bit risky but imo worth a
+shot in -next just for fun. Afaics all these machines have the pci
+resources allocated like that by the BIOS, so I suspect that it's all
+ok.
+
+This regression goes back to
+
+commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu Jul 4 12:28:35 2013 +0100
+
+ drm/i915: Verify that our stolen memory doesn't conflict
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031
+Tested-by: lu hua <huax.lu@intel.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
++++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
+@@ -137,7 +137,11 @@ static unsigned long i915_stolen_to_phys
+ r = devm_request_mem_region(dev->dev, base + 1,
+ dev_priv->gtt.stolen_size - 1,
+ "Graphics Stolen Memory");
+- if (r == NULL) {
++ /*
++ * GEN3 firmware likes to smash pci bridges into the stolen
++ * range. Apparently this works.
++ */
++ if (r == NULL && !IS_GEN3(dev)) {
+ DRM_ERROR("conflict detected with stolen region: [0x%08x - 0x%08x]\n",
+ base, base + (uint32_t)dev_priv->gtt.stolen_size);
+ base = 0;
--- /dev/null
+From 2b387059817fd100cddc5a97118d63e3f3fade74 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Mon, 24 Nov 2014 08:03:12 +0000
+Subject: drm/i915: Only warn the first time we attempt to mmio whilst suspended
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 2b387059817fd100cddc5a97118d63e3f3fade74 upstream.
+
+In all likelihood we will do a few hundred errnoneous register
+operations if we do a single invalid register access whilst the device
+is suspended. As each instance causes a WARN, this floods the system
+logs and can make the system unresponsive.
+
+The warning was first introduced in
+commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
+Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Date: Fri Feb 21 13:52:25 2014 -0300
+
+ drm/i915: call assert_device_not_suspended at gen6_force_wake_work
+
+and despite the claims the WARN is still encountered in the wild today.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Cc: Imre Deak <imre.deak@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_uncore.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_uncore.c
++++ b/drivers/gpu/drm/i915/intel_uncore.c
+@@ -43,8 +43,8 @@
+ static void
+ assert_device_not_suspended(struct drm_i915_private *dev_priv)
+ {
+- WARN(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
+- "Device suspended\n");
++ WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
++ "Device suspended\n");
+ }
+
+ static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
--- /dev/null
+From e7d6f7d708290da1b7c92f533444b042c79412e0 Mon Sep 17 00:00:00 2001
+From: Dave Airlie <airlied@redhat.com>
+Date: Mon, 8 Dec 2014 13:23:37 +1000
+Subject: drm/i915: resume MST after reading back hw state
+
+From: Dave Airlie <airlied@redhat.com>
+
+commit e7d6f7d708290da1b7c92f533444b042c79412e0 upstream.
+
+Otherwise the MST resume paths can hit DPMS paths
+which hit state checker paths, which hit WARN_ON,
+because the state checker is inconsistent with the
+hw.
+
+This fixes a bunch of WARN_ON's on resume after
+undocking.
+
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_drv.c
++++ b/drivers/gpu/drm/i915/i915_drv.c
+@@ -692,11 +692,12 @@ static int __i915_drm_thaw(struct drm_de
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+ }
+
+- intel_dp_mst_resume(dev);
+ drm_modeset_lock_all(dev);
+ intel_modeset_setup_hw_state(dev, true);
+ drm_modeset_unlock_all(dev);
+
++ intel_dp_mst_resume(dev);
++
+ /*
+ * ... but also need to make sure that hotplug processing
+ * doesn't cause havoc. Like in the driver load code we don't
--- /dev/null
+From 9f49c37635d5c2a801f7670d5fbf0b25ec461f2c Mon Sep 17 00:00:00 2001
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Wed, 10 Dec 2014 12:16:05 -0800
+Subject: drm/i915: save/restore GMBUS freq across suspend/resume on gen4
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jesse Barnes <jbarnes@virtuousgeek.org>
+
+commit 9f49c37635d5c2a801f7670d5fbf0b25ec461f2c upstream.
+
+Should probably just init this in the GMbus code all the time, based on
+the cdclk and HPLL like we do on newer platforms. Ville has code for
+that in a rework branch, but until then we can fix this bug fairly
+easily.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Tested-by: Nikolay <mar.kolya@gmail.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.h | 1 +
+ drivers/gpu/drm/i915/i915_reg.h | 1 +
+ drivers/gpu/drm/i915/i915_suspend.c | 8 ++++++++
+ 3 files changed, 10 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -877,6 +877,7 @@ struct i915_suspend_saved_registers {
+ u32 savePIPEB_LINK_N1;
+ u32 saveMCHBAR_RENDER_STANDBY;
+ u32 savePCH_PORT_HOTPLUG;
++ u16 saveGCDGMBUS;
+ };
+
+ struct vlv_s0ix_state {
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -74,6 +74,7 @@
+ #define I915_GC_RENDER_CLOCK_166_MHZ (0 << 0)
+ #define I915_GC_RENDER_CLOCK_200_MHZ (1 << 0)
+ #define I915_GC_RENDER_CLOCK_333_MHZ (4 << 0)
++#define GCDGMBUS 0xcc
+ #define PCI_LBPC 0xf4 /* legacy/combination backlight modes, also called LBB */
+
+
+--- a/drivers/gpu/drm/i915/i915_suspend.c
++++ b/drivers/gpu/drm/i915/i915_suspend.c
+@@ -328,6 +328,10 @@ int i915_save_state(struct drm_device *d
+ }
+ }
+
++ if (IS_GEN4(dev))
++ pci_read_config_word(dev->pdev, GCDGMBUS,
++ &dev_priv->regfile.saveGCDGMBUS);
++
+ /* Cache mode state */
+ if (INTEL_INFO(dev)->gen < 7)
+ dev_priv->regfile.saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
+@@ -356,6 +360,10 @@ int i915_restore_state(struct drm_device
+ mutex_lock(&dev->struct_mutex);
+
+ i915_gem_restore_fences(dev);
++
++ if (IS_GEN4(dev))
++ pci_write_config_word(dev->pdev, GCDGMBUS,
++ dev_priv->regfile.saveGCDGMBUS);
+ i915_restore_display(dev);
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET)) {
drm-radeon-fix-sad_count-check-for-dce3.patch
drm-radeon-adjust-default-bapm-settings-for-kv.patch
drm-radeon-properly-filter-dp1.2-4k-modes-on-non-dp1.2-hw.patch
+drm-i915-don-t-complain-about-stolen-conflicts-on-gen3.patch
+drm-i915-disallow-pin-ioctl-completely-for-kms-drivers.patch
+drm-i915-only-warn-the-first-time-we-attempt-to-mmio-whilst-suspended.patch
+drm-i915-resume-mst-after-reading-back-hw-state.patch
+drm-i915-save-restore-gmbus-freq-across-suspend-resume-on-gen4.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
