From: Greg Kroah-Hartman Date: Tue, 23 Jul 2013 16:56:46 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.10.3~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6546eba4b923ea4e33f42e53403d24c85df67d37;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: drm-i915-fix-context-sizes-on-hsw.patch drm-i915-fix-up-sdvo-hpd-pins-for-i965g-gm.patch drm-i915-only-clear-write-domains-after-a-successful-wait-seqno.patch --- diff --git a/queue-3.10/drm-i915-fix-context-sizes-on-hsw.patch b/queue-3.10/drm-i915-fix-context-sizes-on-hsw.patch new file mode 100644 index 00000000000..a12aee9ea5a --- /dev/null +++ b/queue-3.10/drm-i915-fix-context-sizes-on-hsw.patch @@ -0,0 +1,68 @@ +From a0de80a0e07032a111230ec92eca563f9d93648d Mon Sep 17 00:00:00 2001 +From: Ben Widawsky +Date: Tue, 25 Jun 2013 21:53:40 -0700 +Subject: drm/i915: Fix context sizes on HSW + +From: Ben Widawsky + +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" +Reviewed-by: Jesse Barnes +Signed-off-by: Ben Widawsky +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.10/drm-i915-fix-up-sdvo-hpd-pins-for-i965g-gm.patch b/queue-3.10/drm-i915-fix-up-sdvo-hpd-pins-for-i965g-gm.patch new file mode 100644 index 00000000000..516ce859177 --- /dev/null +++ b/queue-3.10/drm-i915-fix-up-sdvo-hpd-pins-for-i965g-gm.patch @@ -0,0 +1,90 @@ +From 4f7fd7095d85cd31c86cb9ba87bc301319630ccc Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Mon, 24 Jun 2013 21:33:28 +0200 +Subject: drm/i915: Fix up sdvo hpd pins for i965g/gm + +From: Daniel Vetter + +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 +Cc: Arthur Ranyan +Reported-and-tested-by: Alex Fiestas +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 +Acked-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + 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 | \ diff --git a/queue-3.10/drm-i915-only-clear-write-domains-after-a-successful-wait-seqno.patch b/queue-3.10/drm-i915-only-clear-write-domains-after-a-successful-wait-seqno.patch new file mode 100644 index 00000000000..22b32d489fa --- /dev/null +++ b/queue-3.10/drm-i915-only-clear-write-domains-after-a-successful-wait-seqno.patch @@ -0,0 +1,43 @@ +From daa13e1ca587bc773c1aae415ed1af6554117bd4 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Fri, 28 Jun 2013 16:54:08 +0100 +Subject: drm/i915: Only clear write-domains after a successful wait-seqno + +From: Chris Wilson + +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 +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 +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163 +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.10/series b/queue-3.10/series index 8123df56f2c..deed974c7a1 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -76,3 +76,6 @@ svcrpc-fix-failures-to-handle-1-uid-s.patch 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