--- /dev/null
+From 46efa4abe5712276494adbce102f46e3214632fd Mon Sep 17 00:00:00 2001
+From: Tom O'Rourke <Tom.O'Rourke@intel.com>
+Date: Tue, 10 Feb 2015 23:06:46 -0800
+Subject: drm/i915: Clamp efficient frequency to valid range
+
+From: Tom O'Rourke <Tom.O'Rourke@intel.com>
+
+commit 46efa4abe5712276494adbce102f46e3214632fd upstream.
+
+The efficient frequency (RPe) should stay in the range
+RPn <= RPe <= RP0. The pcode clamps the returned value
+internally on Broadwell but not on Haswell.
+
+Fix for missing range check in
+commit 93ee29203f506582cca2bcec5f05041526d9ab0a
+Author: Tom O'Rourke <Tom.O'Rourke@intel.com>
+Date: Wed Nov 19 14:21:52 2014 -0800
+
+ drm/i915: Use efficient frequency for HSW/BDW
+
+Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html
+Reported-by: Michael Auchter <a@phire.org>
+Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_pm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4625,7 +4625,10 @@ static void gen6_init_rps_frequencies(st
+ &ddcc_status);
+ if (0 == ret)
+ dev_priv->rps.efficient_freq =
+- (ddcc_status >> 8) & 0xff;
++ clamp_t(u8,
++ ((ddcc_status >> 8) & 0xff),
++ dev_priv->rps.min_freq,
++ dev_priv->rps.max_freq);
+ }
+
+ /* Preserve min/max settings in case of re-init */
--- /dev/null
+From d180d2bbb66579e3bf449642b8ec2a76f4014fcd Mon Sep 17 00:00:00 2001
+From: Shobhit Kumar <shobhit.kumar@intel.com>
+Date: Thu, 5 Feb 2015 17:10:56 +0530
+Subject: drm/i915: Correct the IOSF Dev_FN field for IOSF transfers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Shobhit Kumar <shobhit.kumar@intel.com>
+
+commit d180d2bbb66579e3bf449642b8ec2a76f4014fcd upstream.
+
+As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
+device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
+port ID should be enough to identify devices unless they are MFD. The
+SB_DevFn was intended to remove ambiguity in case of these MFD devices.
+
+For non MFD devices the recommendation for the target device IP was to
+ignore these fields, but not all of them followed the recommendation.
+Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
+does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
+of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
+It turned out that this did not follow the recommendation and expected 0
+in this field.
+
+In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
+all devices except target PCI devices.
+
+Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_sideband.c | 26 +++++++++++++-------------
+ 1 file changed, 13 insertions(+), 13 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_sideband.c
++++ b/drivers/gpu/drm/i915/intel_sideband.c
+@@ -82,7 +82,7 @@ u32 vlv_punit_read(struct drm_i915_priva
+ WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
+
+ mutex_lock(&dev_priv->dpio_lock);
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_PUNIT,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_PUNIT,
+ SB_CRRDDA_NP, addr, &val);
+ mutex_unlock(&dev_priv->dpio_lock);
+
+@@ -94,7 +94,7 @@ void vlv_punit_write(struct drm_i915_pri
+ WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
+
+ mutex_lock(&dev_priv->dpio_lock);
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_PUNIT,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_PUNIT,
+ SB_CRWRDA_NP, addr, &val);
+ mutex_unlock(&dev_priv->dpio_lock);
+ }
+@@ -103,7 +103,7 @@ u32 vlv_bunit_read(struct drm_i915_priva
+ {
+ u32 val = 0;
+
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_BUNIT,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_BUNIT,
+ SB_CRRDDA_NP, reg, &val);
+
+ return val;
+@@ -111,7 +111,7 @@ u32 vlv_bunit_read(struct drm_i915_priva
+
+ void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+ {
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_BUNIT,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_BUNIT,
+ SB_CRWRDA_NP, reg, &val);
+ }
+
+@@ -122,7 +122,7 @@ u32 vlv_nc_read(struct drm_i915_private
+ WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
+
+ mutex_lock(&dev_priv->dpio_lock);
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_NC,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_NC,
+ SB_CRRDDA_NP, addr, &val);
+ mutex_unlock(&dev_priv->dpio_lock);
+
+@@ -132,56 +132,56 @@ u32 vlv_nc_read(struct drm_i915_private
+ u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+ {
+ u32 val = 0;
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+ SB_CRRDDA_NP, reg, &val);
+ return val;
+ }
+
+ void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+ {
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+ SB_CRWRDA_NP, reg, &val);
+ }
+
+ u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg)
+ {
+ u32 val = 0;
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCK,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_CCK,
+ SB_CRRDDA_NP, reg, &val);
+ return val;
+ }
+
+ void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+ {
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCK,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_CCK,
+ SB_CRWRDA_NP, reg, &val);
+ }
+
+ u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg)
+ {
+ u32 val = 0;
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_CCU,
+ SB_CRRDDA_NP, reg, &val);
+ return val;
+ }
+
+ void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+ {
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_CCU,
+ SB_CRWRDA_NP, reg, &val);
+ }
+
+ u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
+ {
+ u32 val = 0;
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
+ SB_CRRDDA_NP, reg, &val);
+ return val;
+ }
+
+ void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+ {
+- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
++ vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
+ SB_CRWRDA_NP, reg, &val);
+ }
+
--- /dev/null
+From 0ca09685546fed5fc8f0535204f0626f352140f4 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 24 Nov 2014 16:54:11 +0100
+Subject: drm/i915: Drop vblank wait from intel_dp_link_down
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 0ca09685546fed5fc8f0535204f0626f352140f4 upstream.
+
+Nothing in Bspec seems to indicate that we actually needs this, and it
+looks like can't work since by this point the pipe is off and so
+vblanks won't really happen any more.
+
+Note that Bspec mentions that it takes a vblank for this bit to
+change, but _only_ when enabling.
+
+Dropping this code quenches an annoying backtrace introduced by the
+more anal checking since
+
+commit 51e31d49c89055299e34b8f44d13f70e19aaaad1
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon Sep 15 12:36:02 2014 +0200
+
+ drm/i915: Use generic vblank wait
+
+Note: This fixes the fallout from the above commit, but does not address
+the shortcomings of the IBX transcoder select workaround implementation
+discussed during review [1].
+
+[1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_dp.c | 17 +----------------
+ 1 file changed, 1 insertion(+), 16 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -3515,8 +3515,6 @@ intel_dp_link_down(struct intel_dp *inte
+ enum port port = intel_dig_port->port;
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+- struct intel_crtc *intel_crtc =
+- to_intel_crtc(intel_dig_port->base.base.crtc);
+ uint32_t DP = intel_dp->DP;
+
+ if (WARN_ON(HAS_DDI(dev)))
+@@ -3541,8 +3539,6 @@ intel_dp_link_down(struct intel_dp *inte
+
+ if (HAS_PCH_IBX(dev) &&
+ I915_READ(intel_dp->output_reg) & DP_PIPEB_SELECT) {
+- struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
+-
+ /* Hardware workaround: leaving our transcoder select
+ * set to transcoder B while it's off will prevent the
+ * corresponding HDMI output on transcoder A.
+@@ -3553,18 +3549,7 @@ intel_dp_link_down(struct intel_dp *inte
+ */
+ DP &= ~DP_PIPEB_SELECT;
+ I915_WRITE(intel_dp->output_reg, DP);
+-
+- /* Changes to enable or select take place the vblank
+- * after being written.
+- */
+- if (WARN_ON(crtc == NULL)) {
+- /* We should never try to disable a port without a crtc
+- * attached. For paranoia keep the code around for a
+- * bit. */
+- POSTING_READ(intel_dp->output_reg);
+- msleep(50);
+- } else
+- intel_wait_for_vblank(dev, intel_crtc->pipe);
++ POSTING_READ(intel_dp->output_reg);
+ }
+
+ DP &= ~DP_AUDIO_OUTPUT_ENABLE;
--- /dev/null
+From f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 22 Jan 2015 13:42:00 +0000
+Subject: drm/i915: Insert a command barrier on BLT/BSD cache flushes
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf upstream.
+
+This looked like an odd regression from
+
+commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu Jun 12 10:28:55 2014 +0100
+
+ drm/i915: Restrict GPU boost to the RCS engine
+
+but in reality it undercovered a much older coherency bug. The issue that
+boosting the GPU frequency on the BCS ring was masking was that we could
+wake the CPU up after completion of a BCS batch and inspect memory prior
+to the write cache being fully evicted. In order to serialise the
+breadcrumb interrupt (and so ensure that the CPU's view of memory is
+coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.
+
+v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).
+
+Also fix the invalidate_domains mask in gen8_emit_flush() for ring !=
+VCS.
+
+Testcase: gpuX-rcs-gpu-read-after-write
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Acked-by: Daniel Vetter <daniel@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_lrc.c | 20 +++++++++++---------
+ drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +++++++++++++++++++----
+ 2 files changed, 30 insertions(+), 13 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_lrc.c
++++ b/drivers/gpu/drm/i915/intel_lrc.c
+@@ -1237,15 +1237,17 @@ static int gen8_emit_flush(struct intel_
+
+ cmd = MI_FLUSH_DW + 1;
+
+- if (ring == &dev_priv->ring[VCS]) {
+- if (invalidate_domains & I915_GEM_GPU_DOMAINS)
+- cmd |= MI_INVALIDATE_TLB | MI_INVALIDATE_BSD |
+- MI_FLUSH_DW_STORE_INDEX |
+- MI_FLUSH_DW_OP_STOREDW;
+- } else {
+- if (invalidate_domains & I915_GEM_DOMAIN_RENDER)
+- cmd |= MI_INVALIDATE_TLB | MI_FLUSH_DW_STORE_INDEX |
+- MI_FLUSH_DW_OP_STOREDW;
++ /* We always require a command barrier so that subsequent
++ * commands, such as breadcrumb interrupts, are strictly ordered
++ * wrt the contents of the write cache being flushed to memory
++ * (and thus being coherent from the CPU).
++ */
++ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
++
++ if (invalidate_domains & I915_GEM_GPU_DOMAINS) {
++ cmd |= MI_INVALIDATE_TLB;
++ if (ring == &dev_priv->ring[VCS])
++ cmd |= MI_INVALIDATE_BSD;
+ }
+
+ intel_logical_ring_emit(ringbuf, cmd);
+--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
++++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
+@@ -2178,6 +2178,14 @@ static int gen6_bsd_ring_flush(struct in
+ cmd = MI_FLUSH_DW;
+ if (INTEL_INFO(ring->dev)->gen >= 8)
+ cmd += 1;
++
++ /* We always require a command barrier so that subsequent
++ * commands, such as breadcrumb interrupts, are strictly ordered
++ * wrt the contents of the write cache being flushed to memory
++ * (and thus being coherent from the CPU).
++ */
++ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
++
+ /*
+ * Bspec vol 1c.5 - video engine command streamer:
+ * "If ENABLED, all TLBs will be invalidated once the flush
+@@ -2185,8 +2193,8 @@ static int gen6_bsd_ring_flush(struct in
+ * Post-Sync Operation field is a value of 1h or 3h."
+ */
+ if (invalidate & I915_GEM_GPU_DOMAINS)
+- cmd |= MI_INVALIDATE_TLB | MI_INVALIDATE_BSD |
+- MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
++ cmd |= MI_INVALIDATE_TLB | MI_INVALIDATE_BSD;
++
+ intel_ring_emit(ring, cmd);
+ intel_ring_emit(ring, I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT);
+ if (INTEL_INFO(ring->dev)->gen >= 8) {
+@@ -2282,6 +2290,14 @@ static int gen6_ring_flush(struct intel_
+ cmd = MI_FLUSH_DW;
+ if (INTEL_INFO(ring->dev)->gen >= 8)
+ cmd += 1;
++
++ /* We always require a command barrier so that subsequent
++ * commands, such as breadcrumb interrupts, are strictly ordered
++ * wrt the contents of the write cache being flushed to memory
++ * (and thus being coherent from the CPU).
++ */
++ cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
++
+ /*
+ * Bspec vol 1c.3 - blitter engine command streamer:
+ * "If ENABLED, all TLBs will be invalidated once the flush
+@@ -2289,8 +2305,7 @@ static int gen6_ring_flush(struct intel_
+ * Post-Sync Operation field is a value of 1h or 3h."
+ */
+ if (invalidate & I915_GEM_DOMAIN_RENDER)
+- cmd |= MI_INVALIDATE_TLB | MI_FLUSH_DW_STORE_INDEX |
+- MI_FLUSH_DW_OP_STOREDW;
++ cmd |= MI_INVALIDATE_TLB;
+ intel_ring_emit(ring, cmd);
+ intel_ring_emit(ring, I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT);
+ if (INTEL_INFO(ring->dev)->gen >= 8) {
--- /dev/null
+From 460822b0b1a77db859b0320469799fa4dbe4d367 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Micha=C5=82=20Winiarski?= <michal.winiarski@intel.com>
+Date: Tue, 3 Feb 2015 15:48:17 +0100
+Subject: drm/i915: Prevent use-after-free in invalidate_range_start callback
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Micha=C5=82=20Winiarski?= <michal.winiarski@intel.com>
+
+commit 460822b0b1a77db859b0320469799fa4dbe4d367 upstream.
+
+It's possible for invalidate_range_start mmu notifier callback to race
+against userptr object release. If the gem object was released prior to
+obtaining the spinlock in invalidate_range_start we're hitting null
+pointer dereference.
+
+Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
+Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+[Jani: added code comment suggested by Chris]
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_userptr.c | 20 ++++++++++++++++++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
++++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
+@@ -113,7 +113,10 @@ restart:
+ continue;
+
+ obj = mo->obj;
+- drm_gem_object_reference(&obj->base);
++
++ if (!kref_get_unless_zero(&obj->base.refcount))
++ continue;
++
+ spin_unlock(&mn->lock);
+
+ cancel_userptr(obj);
+@@ -149,7 +152,20 @@ static void i915_gem_userptr_mn_invalida
+ it = interval_tree_iter_first(&mn->objects, start, end);
+ if (it != NULL) {
+ obj = container_of(it, struct i915_mmu_object, it)->obj;
+- drm_gem_object_reference(&obj->base);
++
++ /* The mmu_object is released late when destroying the
++ * GEM object so it is entirely possible to gain a
++ * reference on an object in the process of being freed
++ * since our serialisation is via the spinlock and not
++ * the struct_mutex - and consequently use it after it
++ * is freed and then double free it.
++ */
++ if (!kref_get_unless_zero(&obj->base.refcount)) {
++ spin_unlock(&mn->lock);
++ serial = 0;
++ continue;
++ }
++
+ serial = mn->serial;
+ }
+ spin_unlock(&mn->lock);
--- /dev/null
+From a53fa43873b88bad15a2eb1f01dc5efa689625ce Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
+Date: Wed, 4 Feb 2015 10:19:51 +0900
+Subject: drm/radeon: Don't try to enable write-combining without PAT
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
+
+commit a53fa43873b88bad15a2eb1f01dc5efa689625ce upstream.
+
+Doing so can cause things to become slow.
+
+Print a warning at compile time and an informative message at runtime in
+that case.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_object.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_object.c
++++ b/drivers/gpu/drm/radeon/radeon_object.c
+@@ -238,6 +238,18 @@ int radeon_bo_create(struct radeon_devic
+ * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
+ */
+ bo->flags &= ~RADEON_GEM_GTT_WC;
++#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
++ /* Don't try to enable write-combining when it can't work, or things
++ * may be slow
++ * See https://bugs.freedesktop.org/show_bug.cgi?id=88758
++ */
++
++#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
++ thanks to write-combining
++
++ DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
++ "better performance thanks to write-combining\n");
++ bo->flags &= ~RADEON_GEM_GTT_WC;
+ #endif
+
+ radeon_ttm_placement_from_domain(bo, domain);
--- /dev/null
+From 66c2b84ba6256bc5399eed45582af9ebb3ba2c15 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 11 Feb 2015 18:34:36 -0500
+Subject: drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 66c2b84ba6256bc5399eed45582af9ebb3ba2c15 upstream.
+
+Don't restrict it to just eDP panels. Some LVDS bridge chips require
+this. Fixes blank panels on resume on certain laptops. Noticed
+by mrnuke on IRC.
+
+bug:
+https://bugs.freedesktop.org/show_bug.cgi?id=42960
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/atombios_dp.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/atombios_dp.c
++++ b/drivers/gpu/drm/radeon/atombios_dp.c
+@@ -623,10 +623,8 @@ static int radeon_dp_link_train_init(str
+ drm_dp_dpcd_writeb(dp_info->aux,
+ DP_DOWNSPREAD_CTRL, 0);
+
+- if ((dp_info->connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+- (dig->panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
++ if (dig->panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)
+ drm_dp_dpcd_writeb(dp_info->aux, DP_EDP_CONFIGURATION_SET, 1);
+- }
+
+ /* set the lane count on the sink */
+ tmp = dp_info->dp_lane_count;
--- /dev/null
+From 09b6e85fc868568e1b2820235a2a851aecbccfcc Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 12 Feb 2015 00:40:58 -0500
+Subject: drm/radeon: fix voltage setup on hawaii
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 09b6e85fc868568e1b2820235a2a851aecbccfcc upstream.
+
+Missing parameter when fetching the real voltage values
+from atom. Fixes problems with dynamic clocking on
+certain boards.
+
+bug:
+https://bugs.freedesktop.org/show_bug.cgi?id=87457
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_atombios.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_atombios.c
++++ b/drivers/gpu/drm/radeon/radeon_atombios.c
+@@ -3289,6 +3289,7 @@ int radeon_atom_get_voltage_evv(struct r
+
+ args.in.ucVoltageType = VOLTAGE_TYPE_VDDC;
+ args.in.ucVoltageMode = ATOM_GET_VOLTAGE_EVV_VOLTAGE;
++ args.in.usVoltageLevel = cpu_to_le16(virtual_voltage_id);
+ args.in.ulSCLKFreq =
+ cpu_to_le32(rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries[entry_id].clk);
+
--- /dev/null
+From 410af8d7285a0b96314845c75c39fd612b755688 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 6 Feb 2015 12:53:27 -0500
+Subject: drm/radeon: only enable kv/kb dpm interrupts once v3
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 410af8d7285a0b96314845c75c39fd612b755688 upstream.
+
+Enable at init and disable on fini. Workaround for hardware problems.
+
+v2 (chk): extend commit message
+v3: add new function
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/cik.c | 21 ---------------------
+ drivers/gpu/drm/radeon/kv_dpm.c | 17 +++++++++++++++--
+ 2 files changed, 15 insertions(+), 23 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/cik.c
++++ b/drivers/gpu/drm/radeon/cik.c
+@@ -7334,7 +7334,6 @@ int cik_irq_set(struct radeon_device *rd
+ u32 hpd1, hpd2, hpd3, hpd4, hpd5, hpd6;
+ u32 grbm_int_cntl = 0;
+ u32 dma_cntl, dma_cntl1;
+- u32 thermal_int;
+
+ if (!rdev->irq.installed) {
+ WARN(1, "Can't enable IRQ/MSI because no handler is installed\n");
+@@ -7364,13 +7363,6 @@ int cik_irq_set(struct radeon_device *rd
+
+ cp_m1p0 = RREG32(CP_ME1_PIPE0_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
+
+- if (rdev->flags & RADEON_IS_IGP)
+- thermal_int = RREG32_SMC(CG_THERMAL_INT_CTRL) &
+- ~(THERM_INTH_MASK | THERM_INTL_MASK);
+- else
+- thermal_int = RREG32_SMC(CG_THERMAL_INT) &
+- ~(THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW);
+-
+ /* enable CP interrupts on all rings */
+ if (atomic_read(&rdev->irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
+ DRM_DEBUG("cik_irq_set: sw int gfx\n");
+@@ -7474,14 +7466,6 @@ int cik_irq_set(struct radeon_device *rd
+ hpd6 |= DC_HPDx_INT_EN;
+ }
+
+- if (rdev->irq.dpm_thermal) {
+- DRM_DEBUG("dpm thermal\n");
+- if (rdev->flags & RADEON_IS_IGP)
+- thermal_int |= THERM_INTH_MASK | THERM_INTL_MASK;
+- else
+- thermal_int |= THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW;
+- }
+-
+ WREG32(CP_INT_CNTL_RING0, cp_int_cntl);
+
+ WREG32(SDMA0_CNTL + SDMA0_REGISTER_OFFSET, dma_cntl);
+@@ -7528,11 +7512,6 @@ int cik_irq_set(struct radeon_device *rd
+ WREG32(DC_HPD5_INT_CONTROL, hpd5);
+ WREG32(DC_HPD6_INT_CONTROL, hpd6);
+
+- if (rdev->flags & RADEON_IS_IGP)
+- WREG32_SMC(CG_THERMAL_INT_CTRL, thermal_int);
+- else
+- WREG32_SMC(CG_THERMAL_INT, thermal_int);
+-
+ return 0;
+ }
+
+--- a/drivers/gpu/drm/radeon/kv_dpm.c
++++ b/drivers/gpu/drm/radeon/kv_dpm.c
+@@ -1169,6 +1169,19 @@ void kv_dpm_enable_bapm(struct radeon_de
+ }
+ }
+
++static void kv_enable_thermal_int(struct radeon_device *rdev, bool enable)
++{
++ u32 thermal_int;
++
++ thermal_int = RREG32_SMC(CG_THERMAL_INT_CTRL);
++ if (enable)
++ thermal_int |= THERM_INTH_MASK | THERM_INTL_MASK;
++ else
++ thermal_int &= ~(THERM_INTH_MASK | THERM_INTL_MASK);
++ WREG32_SMC(CG_THERMAL_INT_CTRL, thermal_int);
++
++}
++
+ int kv_dpm_enable(struct radeon_device *rdev)
+ {
+ struct kv_power_info *pi = kv_get_pi(rdev);
+@@ -1280,8 +1293,7 @@ int kv_dpm_late_enable(struct radeon_dev
+ DRM_ERROR("kv_set_thermal_temperature_range failed\n");
+ return ret;
+ }
+- rdev->irq.dpm_thermal = true;
+- radeon_irq_set(rdev);
++ kv_enable_thermal_int(rdev, true);
+ }
+
+ /* powerdown unused blocks for now */
+@@ -1312,6 +1324,7 @@ void kv_dpm_disable(struct radeon_device
+ kv_stop_dpm(rdev);
+ kv_enable_ulv(rdev, false);
+ kv_reset_am(rdev);
++ kv_enable_thermal_int(rdev, false);
+
+ kv_update_current_ps(rdev, rdev->pm.dpm.boot_ps);
+ }
--- /dev/null
+From a9c73a0e022c33954835e66fec3cd744af90ec98 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Tue, 10 Feb 2015 14:26:39 +0100
+Subject: drm/radeon: workaround for CP HW bug on CIK
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+
+commit a9c73a0e022c33954835e66fec3cd744af90ec98 upstream.
+
+Emit the EOP twice to avoid cache flushing problems.
+
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/cik.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/radeon/cik.c
++++ b/drivers/gpu/drm/radeon/cik.c
+@@ -3904,7 +3904,21 @@ void cik_fence_gfx_ring_emit(struct rade
+ struct radeon_ring *ring = &rdev->ring[fence->ring];
+ u64 addr = rdev->fence_drv[fence->ring].gpu_addr;
+
+- /* EVENT_WRITE_EOP - flush caches, send int */
++ /* Workaround for cache flush problems. First send a dummy EOP
++ * event down the pipe with seq one below.
++ */
++ radeon_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
++ radeon_ring_write(ring, (EOP_TCL1_ACTION_EN |
++ EOP_TC_ACTION_EN |
++ EVENT_TYPE(CACHE_FLUSH_AND_INV_TS_EVENT) |
++ EVENT_INDEX(5)));
++ radeon_ring_write(ring, addr & 0xfffffffc);
++ radeon_ring_write(ring, (upper_32_bits(addr) & 0xffff) |
++ DATA_SEL(1) | INT_SEL(0));
++ radeon_ring_write(ring, fence->seq - 1);
++ radeon_ring_write(ring, 0);
++
++ /* Then send the real EOP event down the pipe. */
+ radeon_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
+ radeon_ring_write(ring, (EOP_TCL1_ACTION_EN |
+ EOP_TC_ACTION_EN |
--- /dev/null
+From 31f40f86526b71009973854c1dfe799ee70f7588 Mon Sep 17 00:00:00 2001
+From: David Ung <davidu@nvidia.com>
+Date: Tue, 20 Jan 2015 18:37:35 -0800
+Subject: drm/tegra: Use correct relocation target offsets
+
+From: David Ung <davidu@nvidia.com>
+
+commit 31f40f86526b71009973854c1dfe799ee70f7588 upstream.
+
+When copying a relocation from userspace, copy the correct target
+offset.
+
+Signed-off-by: David Ung <davidu@nvidia.com>
+Fixes: 961e3beae3b2 ("drm/tegra: Make job submission 64-bit safe")
+[treding@nvidia.com: provide a better commit message]
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/tegra/drm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/tegra/drm.c
++++ b/drivers/gpu/drm/tegra/drm.c
+@@ -190,7 +190,7 @@ static int host1x_reloc_copy_from_user(s
+ if (err < 0)
+ return err;
+
+- err = get_user(dest->target.offset, &src->cmdbuf.offset);
++ err = get_user(dest->target.offset, &src->target.offset);
+ if (err < 0)
+ return err;
+
mm-fix-negative-nr_isolated-counts.patch
mm-nommu-fix-memory-leak.patch
mm-page_alloc-revert-inadvertent-__gfp_fs-retry-behavior-change.patch
+drm-tegra-use-correct-relocation-target-offsets.patch
+drm-radeon-don-t-try-to-enable-write-combining-without-pat.patch
+drm-radeon-only-enable-kv-kb-dpm-interrupts-once-v3.patch
+drm-radeon-workaround-for-cp-hw-bug-on-cik.patch
+drm-radeon-dp-set-edp_configuration_set-for-bridge-chips-if-necessary.patch
+drm-radeon-fix-voltage-setup-on-hawaii.patch
+drm-i915-insert-a-command-barrier-on-blt-bsd-cache-flushes.patch
+drm-i915-drop-vblank-wait-from-intel_dp_link_down.patch
+drm-i915-prevent-use-after-free-in-invalidate_range_start-callback.patch
+drm-i915-correct-the-iosf-dev_fn-field-for-iosf-transfers.patch
+drm-i915-clamp-efficient-frequency-to-valid-range.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
