--- /dev/null
+From a0de80a0e07032a111230ec92eca563f9d93648d Mon Sep 17 00:00:00 2001
+From: Ben Widawsky <ben@bwidawsk.net>
+Date: Tue, 25 Jun 2013 21:53:40 -0700
+Subject: drm/i915: Fix context sizes on HSW
+
+From: Ben Widawsky <ben@bwidawsk.net>
+
+commit a0de80a0e07032a111230ec92eca563f9d93648d upstream.
+
+With updates to the spec, we can actually see the context layout, and
+how many dwords are allocated. That table suggests we need 70720 bytes
+per HW context. Rounded up, this is 18 pages. Looking at what lives
+after the current 4 pages we use, I can't see too much important (mostly
+it's d3d related), but there are a couple of things which look scary. I
+am hopeful this can explain some of our odd HSW failures.
+
+v2: Make the context only 17 pages. The power context space isn't used
+ever, and execlists aren't used in our driver, making the actual total
+66944 bytes.
+
+v3: Add a comment to the code. (Jesse & Paulo)
+
+Reported-by: "Azad, Vinit" <vinit.azad@intel.com>
+Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
+ drivers/gpu/drm/i915/i915_reg.h | 15 +++++++--------
+ 2 files changed, 8 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem_context.c
++++ b/drivers/gpu/drm/i915/i915_gem_context.c
+@@ -113,7 +113,7 @@ static int get_context_size(struct drm_d
+ case 7:
+ reg = I915_READ(GEN7_CXT_SIZE);
+ if (IS_HASWELL(dev))
+- ret = HSW_CXT_TOTAL_SIZE(reg) * 64;
++ ret = HSW_CXT_TOTAL_SIZE;
+ else
+ ret = GEN7_CXT_TOTAL_SIZE(reg) * 64;
+ break;
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -1535,14 +1535,13 @@
+ GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \
+ GEN7_CXT_GT1_SIZE(ctx_reg) + \
+ GEN7_CXT_VFSTATE_SIZE(ctx_reg))
+-#define HSW_CXT_POWER_SIZE(ctx_reg) ((ctx_reg >> 26) & 0x3f)
+-#define HSW_CXT_RING_SIZE(ctx_reg) ((ctx_reg >> 23) & 0x7)
+-#define HSW_CXT_RENDER_SIZE(ctx_reg) ((ctx_reg >> 15) & 0xff)
+-#define HSW_CXT_TOTAL_SIZE(ctx_reg) (HSW_CXT_POWER_SIZE(ctx_reg) + \
+- HSW_CXT_RING_SIZE(ctx_reg) + \
+- HSW_CXT_RENDER_SIZE(ctx_reg) + \
+- GEN7_CXT_VFSTATE_SIZE(ctx_reg))
+-
++/* Haswell does have the CXT_SIZE register however it does not appear to be
++ * valid. Now, docs explain in dwords what is in the context object. The full
++ * size is 70720 bytes, however, the power context and execlist context will
++ * never be saved (power context is stored elsewhere, and execlists don't work
++ * on HSW) - so the final size is 66944 bytes, which rounds to 17 pages.
++ */
++#define HSW_CXT_TOTAL_SIZE (17 * PAGE_SIZE)
+
+ /*
+ * Overlay regs
--- /dev/null
+From 4f7fd7095d85cd31c86cb9ba87bc301319630ccc Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 24 Jun 2013 21:33:28 +0200
+Subject: drm/i915: Fix up sdvo hpd pins for i965g/gm
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 4f7fd7095d85cd31c86cb9ba87bc301319630ccc upstream.
+
+Bspec seems to be full of lies, at least it disagress with reality:
+Two systems corrobated that SDVO hpd bits are the same as on gen3.
+
+v2: Update comment a bit.
+
+Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
+Reported-and-tested-by: Alex Fiestas <afiestas@kde.org>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
+Acked-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/i915_irq.c | 13 ++-----------
+ drivers/gpu/drm/i915/i915_reg.h | 13 ++++++-------
+ 2 files changed, 8 insertions(+), 18 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -70,15 +70,6 @@ static const u32 hpd_status_gen4[] = {
+ [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
+ };
+
+-static const u32 hpd_status_i965[] = {
+- [HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
+- [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I965,
+- [HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_I965,
+- [HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
+- [HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
+- [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
+-};
+-
+ static const u32 hpd_status_i915[] = { /* i915 and valleyview are the same */
+ [HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
+ [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I915,
+@@ -2952,13 +2943,13 @@ static irqreturn_t i965_irq_handler(int
+ u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+ u32 hotplug_trigger = hotplug_status & (IS_G4X(dev) ?
+ HOTPLUG_INT_STATUS_G4X :
+- HOTPLUG_INT_STATUS_I965);
++ HOTPLUG_INT_STATUS_I915);
+
+ DRM_DEBUG_DRIVER("hotplug event received, stat 0x%08x\n",
+ hotplug_status);
+ if (hotplug_trigger) {
+ if (hotplug_irq_storm_detect(dev, hotplug_trigger,
+- IS_G4X(dev) ? hpd_status_gen4 : hpd_status_i965))
++ IS_G4X(dev) ? hpd_status_gen4 : hpd_status_i915))
+ i915_hpd_irq_setup(dev);
+ queue_work(dev_priv->wq,
+ &dev_priv->hotplug_work);
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -1691,6 +1691,12 @@
+ /* SDVO is different across gen3/4 */
+ #define SDVOC_HOTPLUG_INT_STATUS_G4X (1 << 3)
+ #define SDVOB_HOTPLUG_INT_STATUS_G4X (1 << 2)
++/*
++ * Bspec seems to be seriously misleaded about the SDVO hpd bits on i965g/gm,
++ * since reality corrobates that they're the same as on gen3. But keep these
++ * bits here (and the comment!) to help any other lost wanderers back onto the
++ * right tracks.
++ */
+ #define SDVOC_HOTPLUG_INT_STATUS_I965 (3 << 4)
+ #define SDVOB_HOTPLUG_INT_STATUS_I965 (3 << 2)
+ #define SDVOC_HOTPLUG_INT_STATUS_I915 (1 << 7)
+@@ -1701,13 +1707,6 @@
+ PORTB_HOTPLUG_INT_STATUS | \
+ PORTC_HOTPLUG_INT_STATUS | \
+ PORTD_HOTPLUG_INT_STATUS)
+-
+-#define HOTPLUG_INT_STATUS_I965 (CRT_HOTPLUG_INT_STATUS | \
+- SDVOB_HOTPLUG_INT_STATUS_I965 | \
+- SDVOC_HOTPLUG_INT_STATUS_I965 | \
+- PORTB_HOTPLUG_INT_STATUS | \
+- PORTC_HOTPLUG_INT_STATUS | \
+- PORTD_HOTPLUG_INT_STATUS)
+
+ #define HOTPLUG_INT_STATUS_I915 (CRT_HOTPLUG_INT_STATUS | \
+ SDVOB_HOTPLUG_INT_STATUS_I915 | \
--- /dev/null
+From daa13e1ca587bc773c1aae415ed1af6554117bd4 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri, 28 Jun 2013 16:54:08 +0100
+Subject: drm/i915: Only clear write-domains after a successful wait-seqno
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit daa13e1ca587bc773c1aae415ed1af6554117bd4 upstream.
+
+In the introduction of the non-blocking wait, I cut'n'pasted the wait
+completion code from normal locked path. Unfortunately, this neglected
+that the normal path returned early if the wait returned early. The
+result is that read-only waits may return whilst the GPU is still
+writing to the bo.
+
+Fixes regression from
+commit 3236f57a0162391f84b93f39fc1882c49a8998c7 [v3.7]
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Fri Aug 24 09:35:09 2012 +0100
+
+ drm/i915: Use a non-blocking wait for set-to-domain ioctl
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -1160,7 +1160,8 @@ i915_gem_object_wait_rendering__nonblock
+ /* Manually manage the write flush as we may have not yet
+ * retired the buffer.
+ */
+- if (obj->last_write_seqno &&
++ if (ret == 0 &&
++ obj->last_write_seqno &&
+ i915_seqno_passed(seqno, obj->last_write_seqno)) {
+ obj->last_write_seqno = 0;
+ obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS;
svcrpc-fix-handling-of-too-short-rpc-s.patch
svcrpc-don-t-error-out-on-small-tcp-fragment.patch
of-fix-address-decoding-on-bimini-and-js2x-machines.patch
+drm-i915-fix-up-sdvo-hpd-pins-for-i965g-gm.patch
+drm-i915-fix-context-sizes-on-hsw.patch
+drm-i915-only-clear-write-domains-after-a-successful-wait-seqno.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
