Broadwell 3.14 backports

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/intel_uncore.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

drivers/gpu/drm/i915/intel_uncore.c +10 -9

index 87df68f..6df5ec4 100644
@@ -634,16 +634,17 @@ static bool is_gen8_shadowed(struct drm_i915_private *dev_priv, u32 reg)
 #define __gen8_write(x) \
 static void \
 gen8_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace) { \
-	bool __needs_put = reg < 0x40000 && !is_gen8_shadowed(dev_priv, reg); \
 	REG_WRITE_HEADER; \
-	if (__needs_put) { \
-		dev_priv->uncore.funcs.force_wake_get(dev_priv, \
-							FORCEWAKE_ALL); \
-	} \
-	__raw_i915_write##x(dev_priv, reg, val); \
-	if (__needs_put) { \
-		dev_priv->uncore.funcs.force_wake_put(dev_priv, \
-							FORCEWAKE_ALL); \
+	if (reg < 0x40000 && !is_gen8_shadowed(dev_priv, reg)) { \
+		if (dev_priv->uncore.forcewake_count == 0) \
+			dev_priv->uncore.funcs.force_wake_get(dev_priv,	\
+							      FORCEWAKE_ALL); \
+		__raw_i915_write##x(dev_priv, reg, val); \
+		if (dev_priv->uncore.forcewake_count == 0) \
+			dev_priv->uncore.funcs.force_wake_put(dev_priv, \
+							      FORCEWAKE_ALL); \
+	} else { \
+		__raw_i915_write##x(dev_priv, reg, val); \
 	} \
 	REG_WRITE_FOOTER; \
 }

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #2 lore raw

PATCH 2/12 drm/i915: Do forcewake reset on gen8

From: Mika Kuoppala <[email protected]>

When we get control from BIOS there might be mt forcewake bits already set. This causes us to do double mt get without proper clear/ack sequence.

Fix this by clearing mt forcewake register on init, like we do with older gens.

Signed-off-by Mika Kuoppala <[email protected]>

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/intel_uncore.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/gpu/drm/i915/intel_uncore.c +5 -5

index 6df5ec4..5f1762b 100644
@@ -305,13 +305,13 @@ static void intel_uncore_forcewake_reset(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
-	if (IS_VALLEYVIEW(dev)) {
+	if (IS_VALLEYVIEW(dev))
 		vlv_force_wake_reset(dev_priv);
-	} else if (INTEL_INFO(dev)->gen >= 6) {
+	else if (IS_GEN6(dev) || IS_GEN7(dev))
 		__gen6_gt_force_wake_reset(dev_priv);
-		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
-			__gen6_gt_force_wake_mt_reset(dev_priv);
-	}
+
+	if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_GEN8(dev))
+		__gen6_gt_force_wake_mt_reset(dev_priv);
 }
 
 void intel_uncore_early_sanitize(struct drm_device *dev)

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #3 lore raw

PATCH 3/12 drm/i915: Disable semaphore wait event idle message on BDW

From: Ville Syrjälä <[email protected]>

According to BSpec we need to always set this magic bit in ring buffer mode.

Reviewed-by Mika Kuoppala <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/intel_pm.c
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 3 +++
 2 files changed, 6 insertions(+)

drivers/gpu/drm/i915/i915_reg.h +3 -0

index a48b7ca..1240250 100644
@@ -941,6 +941,9 @@
 #define   GEN6_BLITTER_LOCK_SHIFT			16
 #define   GEN6_BLITTER_FBC_NOTIFY			(1<<3)
 
+#define GEN6_RC_SLEEP_PSMI_CONTROL	0x2050
+#define   GEN8_RC_SEMA_IDLE_MSG_DISABLE	(1 << 12)
+
 #define GEN6_BSD_SLEEP_PSMI_CONTROL	0x12050
 #define   GEN6_BSD_SLEEP_MSG_DISABLE	(1 << 0)
 #define   GEN6_BSD_SLEEP_FLUSH_DISABLE	(1 << 2)

drivers/gpu/drm/i915/intel_pm.c +3 -0

index e1fc35a..7b79c18 100644
@@ -4755,6 +4755,9 @@ static void gen8_init_clock_gating(struct drm_device *dev)
 	I915_WRITE(GEN7_FF_THREAD_MODE,
 		   I915_READ(GEN7_FF_THREAD_MODE) &
 		   ~(GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME));
+
+	I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
+		   _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
 }
 
 static void haswell_init_clock_gating(struct drm_device *dev)

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #4 lore raw

PATCH 4/12 drm/i915: Implement WaDisableSDEUnitClockGating:bdw

From: Ville Syrjälä <[email protected]>

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 4 ++++
 2 files changed, 7 insertions(+)

drivers/gpu/drm/i915/i915_reg.h +3 -0

index 1240250..db70031 100644
@@ -4868,6 +4868,9 @@
 #define GEN7_UCGCTL4				0x940c
 #define  GEN7_L3BANK2X_CLOCK_GATE_DISABLE	(1<<25)
 
+#define GEN8_UCGCTL6				0x9430
+#define   GEN8_SDEUNIT_CLOCK_GATE_DISABLE	(1<<14)
+
 #define GEN6_RPNSWREQ				0xA008
 #define   GEN6_TURBO_DISABLE			(1<<31)
 #define   GEN6_FREQUENCY(x)			((x)<<25)

drivers/gpu/drm/i915/intel_pm.c +4 -0

index 7b79c18..a0c6add 100644
@@ -4758,6 +4758,10 @@ static void gen8_init_clock_gating(struct drm_device *dev)
 
 	I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
 		   _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
+
+	/* WaDisableSDEUnitClockGating:bdw */
+	I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
+		   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
 }
 
 static void haswell_init_clock_gating(struct drm_device *dev)

Signature · 6 lines

1.9.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Ben Widawsky

author

2014-03-21 18:48 UTC #5 lore raw

PATCH 5/12 drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw

From: Ville Syrjälä <[email protected]>

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/i915/intel_ringbuffer.c +1 -1

index 31b36c5..2ac8f94 100644
@@ -569,7 +569,7 @@ static int init_render_ring(struct intel_ring_buffer *ring)
 	 * to use MI_WAIT_FOR_EVENT within the CS. It should already be
 	 * programmed to '1' on all products.
 	 *
-	 * WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv
+	 * WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw
 	 */
 	if (INTEL_INFO(dev)->gen >= 6)
 		I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));

Signature · 6 lines

1.9.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Ben Widawsky

author

2014-03-21 18:48 UTC #6 lore raw

PATCH 6/12 drm/i915: Add a partial instruction shootdown workaround on Broadwell.

From: Kenneth Graunke <[email protected]>

I believe this will be necessary on production hardware.

Signed-off-by Kenneth Graunke <[email protected]>

Reviewed-by Ville Syrjälä <[email protected]>

[danvet: Fix whitespace fail spotted by checkpatch. Also add missing :bdw w/a tag that Ville spotted.]

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/intel_pm.c
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 4 ++++
 2 files changed, 7 insertions(+)

drivers/gpu/drm/i915/i915_reg.h +3 -0

index db70031..cb9ff13 100644
@@ -5012,6 +5012,9 @@
 #define   GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE	(1<<10)
 #define   GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE	(1<<3)
 
+#define GEN8_ROW_CHICKEN		0xe4f0
+#define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE	(1<<8)
+
 #define GEN7_ROW_CHICKEN2		0xe4f4
 #define GEN7_ROW_CHICKEN2_GT2		0xf4f4
 #define   DOP_CLOCK_GATING_DISABLE	(1<<0)

drivers/gpu/drm/i915/intel_pm.c +4 -0

index a0c6add..a7e5669 100644
@@ -4713,6 +4713,10 @@ static void gen8_init_clock_gating(struct drm_device *dev)
 
 	WARN(!i915_preliminary_hw_support,
 	     "GEN8_CENTROID_PIXEL_OPT_DIS not be needed for production\n");
+	/* WaDisablePartialInstShootdown:bdw */
+	I915_WRITE(GEN8_ROW_CHICKEN,
+		   _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
+
 	I915_WRITE(HALF_SLICE_CHICKEN3,
 		   _MASKED_BIT_ENABLE(GEN8_CENTROID_PIXEL_OPT_DIS));
 	I915_WRITE(HALF_SLICE_CHICKEN3,

Signature · 6 lines

1.9.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Ben Widawsky

author

2014-03-21 18:48 UTC #7 lore raw

PATCH 7/12 drm/i915: Add thread stall DOP clock gating workaround on Broadwell.

From: Kenneth Graunke <[email protected]>

Ben and I believe this will be necessary on production hardware.

Signed-off-by Kenneth Graunke <[email protected]>

[danvet: Shuffle lines to group all ROW_CHICKEN writes and add a cautious comment that this might not be needed on production hw.]

Reviewed-by Ville Syrjälä <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/intel_pm.c
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

drivers/gpu/drm/i915/i915_reg.h +1 -0

index cb9ff13..d9b2292 100644
@@ -5014,6 +5014,7 @@
 
 #define GEN8_ROW_CHICKEN		0xe4f0
 #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE	(1<<8)
+#define   STALL_DOP_GATING_DISABLE		(1<<5)
 
 #define GEN7_ROW_CHICKEN2		0xe4f4
 #define GEN7_ROW_CHICKEN2_GT2		0xf4f4

drivers/gpu/drm/i915/intel_pm.c +4 -1

index a7e5669..2b82a6b 100644
@@ -4713,9 +4713,12 @@ static void gen8_init_clock_gating(struct drm_device *dev)
 
 	WARN(!i915_preliminary_hw_support,
 	     "GEN8_CENTROID_PIXEL_OPT_DIS not be needed for production\n");
+
 	/* WaDisablePartialInstShootdown:bdw */
+	/* WaDisableThreadStallDopClockGating:bdw */
 	I915_WRITE(GEN8_ROW_CHICKEN,
-		   _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
+		   _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE |
+				      STALL_DOP_GATING_DISABLE));
 
 	I915_WRITE(HALF_SLICE_CHICKEN3,
 		   _MASKED_BIT_ENABLE(GEN8_CENTROID_PIXEL_OPT_DIS));

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #8 lore raw

PATCH 8/12 drm/i915/bdw: The TLB invalidation mechanism has been removed from INSTPM

From: Damien Lespiau <[email protected]>

While wandering in the spec, I noticed that BDW removes those 2 bits from INSTPM. I couldn't find any direct way to invalidate the TLB (ie without the ring working already). Maybe someone will be more lucky.

At least, we now know we may be a problem.

Signed-off-by Damien Lespiau <[email protected]>

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

drivers/gpu/drm/i915/intel_ringbuffer.c +8 -2

index 2ac8f94..c1ee5ef 100644
@@ -977,8 +977,14 @@ void intel_ring_setup_status_page(struct intel_ring_buffer *ring)
 	I915_WRITE(mmio, (u32)ring->status_page.gfx_addr);
 	POSTING_READ(mmio);
 
-	/* Flush the TLB for this page */
-	if (INTEL_INFO(dev)->gen >= 6) {
+	/*
+	 * Flush the TLB for this page
+	 *
+	 * FIXME: These two bits have disappeared on gen8, so a question
+	 * arises: do we still need this and if so how should we go about
+	 * invalidating the TLB?
+	 */
+	if (INTEL_INFO(dev)->gen >= 6 && INTEL_INFO(dev)->gen < 8) {
 		u32 reg = RING_INSTPM(ring->mmio_base);
 		I915_WRITE(reg,
 			   _MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE |

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #9 lore raw

PATCH 9/12 drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW

From: Ville Syrjälä <[email protected]>

Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1 registers with 0xffffffff. Move the parens to the correct place to avoid this.

In particular this caused bit 30 of said registers to be set, which caused the sprite CSC to produce incorrect results.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220

Reviewed-by Damien Lespiau <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/intel_pm.c
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/i915/intel_pm.c +2 -2

index 2b82a6b..f9a63b7 100644
@@ -4745,8 +4745,8 @@ static void gen8_init_clock_gating(struct drm_device *dev)
 	/* WaPsrDPRSUnmaskVBlankInSRD:bdw */
 	for_each_pipe(i) {
 		I915_WRITE(CHICKEN_PIPESL_1(i),
-			   I915_READ(CHICKEN_PIPESL_1(i) |
-				     DPRS_MASK_VBLANK_SRD));
+			   I915_READ(CHICKEN_PIPESL_1(i)) |
+			   DPRS_MASK_VBLANK_SRD);
 	}
 
 	/* Use Force Non-Coherent whenever executing a 3D context. This is a

Signature · 6 lines

1.9.1

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Ben Widawsky

author

2014-03-21 18:48 UTC #10 lore raw

PATCH 10/12 drm/i915: don't flood the logs about bdw semaphores

From: Jani Nikula <[email protected]>

BDW is no longer flagged as preliminary hw, but without i915.preliminary_hw_support module param set the logs are filled with WARNs about it.

Just make semaphores off the BDW per-chip default for now.

CC Ben Widawsky <[email protected]>

Reported-by Sebastien Dufour <[email protected]>

Signed-off-by Jani Nikula <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/i915_drv.c
---
 drivers/gpu/drm/i915/i915_drv.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/gpu/drm/i915/i915_drv.c +4 -1

index ec7bb0f..8b5c305 100644
@@ -477,13 +477,16 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
 
 	/* Until we get further testing... */
 	if (IS_GEN8(dev)) {
-		WARN_ON(!i915_preliminary_hw_support);
 		return false;
 	}
 
 	if (i915_semaphores >= 0)
 		return i915_semaphores;
 
+	/* Until we get further testing... */
+	if (IS_GEN8(dev))
+		return false;
+
 #ifdef CONFIG_INTEL_IOMMU
 	/* Enable semaphores on SNB when IO remapping is off */
 	if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 22:07 UTC #11 lore raw

PATCH v2 10/12 drm/i915: don't flood the logs about bdw semaphores

From: Jani Nikula <[email protected]>

BDW is no longer flagged as preliminary hw, but without i915.preliminary_hw_support module param set the logs are filled with WARNs about it.

Just make semaphores off the BDW per-chip default for now.

v2: Spurious merge hunk leftover in v1 removed

CC Ben Widawsky <[email protected]>

Reported-by Sebastien Dufour <[email protected]>

Signed-off-by Jani Nikula <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/i915_drv.c
---
 drivers/gpu/drm/i915/i915_drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/gpu/drm/i915/i915_drv.c +1 -3

index ec7bb0f..8f16e11 100644
@@ -476,10 +476,8 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
 		return false;
 
 	/* Until we get further testing... */
-	if (IS_GEN8(dev)) {
-		WARN_ON(!i915_preliminary_hw_support);
+	if (IS_GEN8(dev))
 		return false;
-	}
 
 	if (i915_semaphores >= 0)
 		return i915_semaphores;

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #12 lore raw

PATCH 11/12 drm/i915/bdw: Use scratch page table for GEN8 PPGTT

From: Ben Widawsky <[email protected]>

I'm not clear if the hardware is still subject to the same prefetching issues that made us use a scratch page in the first place. In either case, we're using garbage with the current code (we will end up using offset 0).

This may be the cause of our current gem_cpu_reloc regression with PPGTT. I cannot test it at the moment.

Reviewed-by Chris Wilson <[email protected]>

[BDW 3.14 backport]

---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/gpu/drm/i915/i915_gem_gtt.c +2 -0

index 40a2b36..8cc9398 100644
@@ -359,6 +359,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
  **/
 static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt, uint64_t size)
 {
+	struct drm_i915_private *dev_priv = ppgtt->base.dev->dev_private;
 	struct page *pt_pages;
 	int i, j, ret = -ENOMEM;
 	const int max_pdp = DIV_ROUND_UP(size, 1 << 30);

@@ -389,6 +390,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt, uint64_t size)
 	ppgtt->base.clear_range = gen8_ppgtt_clear_range;
 	ppgtt->base.insert_entries = gen8_ppgtt_insert_entries;
 	ppgtt->base.cleanup = gen8_ppgtt_cleanup;
+	ppgtt->base.scratch = dev_priv->gtt.base.scratch;
 	ppgtt->base.start = 0;
 	ppgtt->base.total = ppgtt->num_pt_pages * GEN8_PTES_PER_PAGE * PAGE_SIZE;

Signature · 1 line

1.9.1

Ben Widawsky

author

2014-03-21 18:48 UTC #13 lore raw

PATCH 12/12 drm/i915/bdw: Restore PPAT on thaw

From: Ben Widawsky <[email protected]>

Apparently it is wiped out from under us, and we get some really fun caching artifacts upon resume (it seems to be WB for all types by default).

Reported-by James Ausmus <[email protected]>

Tested-by James Ausmus <[email protected]>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76113

Tested-by Timo Aaltonen <[email protected]>

[BDW 3.14 backport]

Conflicts:

	drivers/gpu/drm/i915/i915_gem_gtt.c
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/gpu/drm/i915/i915_gem_gtt.c +5 -0

index 8cc9398..268e0d3 100644
@@ -28,6 +28,8 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+static void gen8_setup_private_ppat(struct drm_i915_private *dev_priv);
+
 #define GEN6_PPGTT_PD_ENTRIES 512
 #define I915_PPGTT_PT_ENTRIES (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
 typedef uint64_t gen8_gtt_pte_t;

@@ -865,6 +867,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
 		i915_gem_gtt_bind_object(obj, obj->cache_level);
 	}
 
+	if (INTEL_INFO(dev)->gen >= 8)
+		gen8_setup_private_ppat(dev_priv);
+
 	i915_gem_chipset_flush(dev);
 }

Signature · 1 line

1.9.1

Daniel Vetter

2014-03-21 19:49 UTC #14 lore raw

Quoted 28 lines · Ben Widawsky

The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch.
I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner.
Ben Widawsky (2):
drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw
Damien Lespiau (1):
drm/i915/bdw: The TLB invalidation mechanism has been removed from
INSTPM
Jani Nikula (1):
drm/i915: don't flood the logs about bdw semaphores
Kenneth Graunke (2):
drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Mika Kuoppala (2):
drm/i915: Fix forcewake counts for gen8
drm/i915: Do forcewake reset on gen8

Quoted 5 lines

Ville Syrjälä (4):
drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW

The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you.

Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree.

Thanks, Daniel

Quoted 8 lines

 drivers/gpu/drm/i915/i915_drv.c         |  5 ++++-
 drivers/gpu/drm/i915/i915_gem_gtt.c     |  7 +++++++
 drivers/gpu/drm/i915/i915_reg.h         | 10 ++++++++++
 drivers/gpu/drm/i915/intel_pm.c         | 18 ++++++++++++++++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++++++++---
 drivers/gpu/drm/i915/intel_uncore.c     | 29 +++++++++++++++--------------
 6 files changed, 61 insertions(+), 20 deletions(-)

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Ben Widawsky

author

2014-03-21 22:14 UTC #15 lore raw

Quoted 36 lines · Daniel Vetter

Quoted 28 lines · Ben Widawsky
The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch.
I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner.
Ben Widawsky (2):
drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw
Damien Lespiau (1):
drm/i915/bdw: The TLB invalidation mechanism has been removed from
INSTPM
Jani Nikula (1):
drm/i915: don't flood the logs about bdw semaphores
Kenneth Graunke (2):
drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Mika Kuoppala (2):
drm/i915: Fix forcewake counts for gen8
drm/i915: Do forcewake reset on gen8
Quoted 5 lines
Ville Syrjälä (4):
drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW

Quoted 3 lines

The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you.

I decided not to do this because in the git help it says, "This is done only for cherry picks without conflicts." I believe only one of these patches didn't actually have a conflict (so I should have done it for that). So I will assume I should ignore this recommendation from the git help. I didn't want to make it seem like these patches did not have conflicts.

Quoted 9 lines

Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree.

Since you added Greg, I am curious - as noted in the cover letter, I've done the merge conflict resolution on the patches which already had Cc:
stable. I didn't intentionally include any patches which already had Cc:
stable and didn't require conflict resolution. Are those interesting/useful, should I drop them from the series?

Quoted 18 lines

Thanks, Daniel

Quoted 8 lines

 drivers/gpu/drm/i915/i915_drv.c         |  5 ++++-
 drivers/gpu/drm/i915/i915_gem_gtt.c     |  7 +++++++
 drivers/gpu/drm/i915/i915_reg.h         | 10 ++++++++++
 drivers/gpu/drm/i915/intel_pm.c         | 18 ++++++++++++++++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++++++++---
 drivers/gpu/drm/i915/intel_uncore.c     | 29 +++++++++++++++--------------
 6 files changed, 61 insertions(+), 20 deletions(-)

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Signature · 5 lines

Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Greg KH

2014-03-21 23:47 UTC #16 lore raw

Quoted 58 lines · Ben Widawsky

Quoted 36 lines · Daniel Vetter
Quoted 28 lines · Ben Widawsky
The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch.
I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner.
Ben Widawsky (2):
drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw
Damien Lespiau (1):
drm/i915/bdw: The TLB invalidation mechanism has been removed from
INSTPM
Jani Nikula (1):
drm/i915: don't flood the logs about bdw semaphores
Kenneth Graunke (2):
drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Mika Kuoppala (2):
drm/i915: Fix forcewake counts for gen8
drm/i915: Do forcewake reset on gen8
Quoted 5 lines
Ville Syrjälä (4):
drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW
Quoted 3 lines
The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you.
I decided not to do this because in the git help it says, "This is done only for cherry picks without conflicts." I believe only one of these patches didn't actually have a conflict (so I should have done it for that). So I will assume I should ignore this recommendation from the git help. I didn't want to make it seem like these patches did not have conflicts.
Quoted 9 lines
Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree.

Quoted 5 lines

Since you added Greg, I am curious - as noted in the cover letter, I've done the merge conflict resolution on the patches which already had Cc:
stable. I didn't intentionally include any patches which already had Cc:
stable and didn't require conflict resolution. Are those interesting/useful, should I drop them from the series?

I have no idea what is going on here, what this original email was from / about, or what I am supposed to do here...

The stable patch process is pretty well defined, and documented, is that lacking somehow, and if so, in what?

greg k-h

Ben Widawsky

author

2014-03-22 00:06 UTC #17 lore raw

Quoted 65 lines · Greg KH

Quoted 58 lines · Ben Widawsky
Quoted 36 lines · Daniel Vetter
Quoted 28 lines · Ben Widawsky
The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch.
I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner.
Ben Widawsky (2):
drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw
Damien Lespiau (1):
drm/i915/bdw: The TLB invalidation mechanism has been removed from
INSTPM
Jani Nikula (1):
drm/i915: don't flood the logs about bdw semaphores
Kenneth Graunke (2):
drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Mika Kuoppala (2):
drm/i915: Fix forcewake counts for gen8
drm/i915: Do forcewake reset on gen8
Quoted 5 lines
Ville Syrjälä (4):
drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW
Quoted 3 lines
The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you.
I decided not to do this because in the git help it says, "This is done only for cherry picks without conflicts." I believe only one of these patches didn't actually have a conflict (so I should have done it for that). So I will assume I should ignore this recommendation from the git help. I didn't want to make it seem like these patches did not have conflicts.
Quoted 9 lines
Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree.
Quoted 5 lines
Since you added Greg, I am curious - as noted in the cover letter, I've done the merge conflict resolution on the patches which already had Cc:
stable. I didn't intentionally include any patches which already had Cc:
stable and didn't require conflict resolution. Are those interesting/useful, should I drop them from the series?

Quoted 7 lines

I have no idea what is going on here, what this original email was from / about, or what I am supposed to do here...
The stable patch process is pretty well defined, and documented, is that lacking somehow, and if so, in what?
greg k-h

My apologies, I didn't understand what Daniel had originally wanted from me, and I think the plan changed a bit in flight. I'm sorry you got dragged into it. The stable process documentation is perfectly adequate.

Signature · 5 lines

Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Ben Widawsky

author

2014-03-22 00:17 UTC #18 lore raw

Quoted 69 lines · Ben Widawsky

Quoted 68 lines · Greg KH
Quoted 58 lines · Ben Widawsky
Quoted 36 lines · Daniel Vetter
Quoted 28 lines · Ben Widawsky
The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch.
I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner.
Ben Widawsky (2):
drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw
Damien Lespiau (1):
drm/i915/bdw: The TLB invalidation mechanism has been removed from
INSTPM
Jani Nikula (1):
drm/i915: don't flood the logs about bdw semaphores
Kenneth Graunke (2):
drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Mika Kuoppala (2):
drm/i915: Fix forcewake counts for gen8
drm/i915: Do forcewake reset on gen8
Quoted 5 lines
Ville Syrjälä (4):
drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW
Quoted 3 lines
The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you.
I decided not to do this because in the git help it says, "This is done only for cherry picks without conflicts." I believe only one of these patches didn't actually have a conflict (so I should have done it for that). So I will assume I should ignore this recommendation from the git help. I didn't want to make it seem like these patches did not have conflicts.
Quoted 9 lines
Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree.
Quoted 5 lines
Since you added Greg, I am curious - as noted in the cover letter, I've done the merge conflict resolution on the patches which already had Cc:
stable. I didn't intentionally include any patches which already had Cc:
stable and didn't require conflict resolution. Are those interesting/useful, should I drop them from the series?
I have no idea what is going on here, what this original email was from / about, or what I am supposed to do here...

Quoted 9 lines

Quoted 4 lines
The stable patch process is pretty well defined, and documented, is that lacking somehow, and if so, in what?
greg k-h
My apologies, I didn't understand what Daniel had originally wanted from me, and I think the plan changed a bit in flight. I'm sorry you got dragged into it. The stable process documentation is perfectly adequate.

And if it wasn't clear, like Daniel said, please ignore these 12 patches for now. Sorry again.

Signature · 5 lines

Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Daniel Vetter

2014-03-22 11:29 UTC #19 lore raw

Quoted 10 lines · Ben Widawsky

Quoted 9 lines · Ben Widawsky
Quoted 7 lines · Greg KH
I have no idea what is going on here, what this original email was from / about, or what I am supposed to do here...
The stable patch process is pretty well defined, and documented, is that lacking somehow, and if so, in what?
greg k-h

Quoted 7 lines

Quoted 4 lines
My apologies, I didn't understand what Daniel had originally wanted from me, and I think the plan changed a bit in flight. I'm sorry you got dragged into it. The stable process documentation is perfectly adequate.
And if it wasn't clear, like Daniel said, please ignore these 12 patches for now. Sorry again.

For clarification: BDW support was enabled for the first time in 3.14, but in the -rc phase suddenly lots of workaround patches and little fixes start to pile in. Since pretty much no one has the hardware already I decided to withold all bdw fixes and queued them for -next. Once it all stabilized we could then reevaluate whether bdw support in 3.14 makes sense or not, i.e. whether to backport a pile of fixes or just disable it again.

bdw seems to have calmed down now and it doesn't look too bad (it's a bit more than these 12 patches here, but all fairly isolated), so I've asked Ben to assemble the required patches, backport and test them and then submit it all to stable (once drm-next has landed, ofc). Ben was a bit overeager and submitted them to stable a bit too early ;-)

My apologies for the fuzz and my unclear communication.

Cheers, Daniel

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Ben Widawsky

2014-03-22 00:51 UTC #20 lore raw