intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drm/i915: fix FORCEWAKE posting reads
@ 2013-01-11  7:53 Jani Nikula
  2013-01-11 18:15 ` Ben Widawsky
  0 siblings, 1 reply; 6+ messages in thread
From: Jani Nikula @ 2013-01-11  7:53 UTC (permalink / raw)
  To: intel-gfx; +Cc: jani.nikula, Ben Widawsky

We stopped reading FORCEWAKE for posting reads in

commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

and started using something from the same cacheline instead. This was true
for ECOBUS, but not for GTFIFODBG. Add posting reads on ECOBUS where
GTFIFODBG was relied on.

In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
well.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
CC: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index abfff29..06b75a1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4122,7 +4122,8 @@ static void __gen6_gt_force_wake_get(struct drm_i915_private *dev_priv)
 static void __gen6_gt_force_wake_mt_reset(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(0xffff));
-	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 }
 
 static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
@@ -4139,7 +4140,8 @@ static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
 		DRM_ERROR("Timed out waiting for forcewake old ack to clear.\n");
 
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
-	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 
 	if (wait_for_atomic((I915_READ_NOTRACE(forcewake_ack) & 1),
 			    FORCEWAKE_ACK_TIMEOUT_MS))
@@ -4176,14 +4178,16 @@ void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv)
 static void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE, 0);
-	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE */
+	POSTING_READ(ECOBUS);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
 static void __gen6_gt_force_wake_mt_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
-	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
@@ -4223,6 +4227,8 @@ int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 static void vlv_force_wake_reset(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(0xffff));
+	/* something from same cacheline, but !FORCEWAKE_VLV */
+	POSTING_READ(FORCEWAKE_ACK_VLV);
 }
 
 static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
@@ -4243,7 +4249,8 @@ static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
 static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
-	/* The below doubles as a POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE_VLV */
+	POSTING_READ(FORCEWAKE_ACK_VLV);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH] drm/i915: fix FORCEWAKE posting reads
  2013-01-11  7:53 [PATCH] drm/i915: fix FORCEWAKE posting reads Jani Nikula
@ 2013-01-11 18:15 ` Ben Widawsky
  2013-01-17  8:24   ` [PATCH v2] " Jani Nikula
  0 siblings, 1 reply; 6+ messages in thread
From: Ben Widawsky @ 2013-01-11 18:15 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

On Fri, Jan 11, 2013 at 09:53:53AM +0200, Jani Nikula wrote:
> We stopped reading FORCEWAKE for posting reads in
> 
> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Sat Sep 1 22:59:50 2012 -0700
> 
>     drm/i915: Never read FORCEWAKE
> 
> and started using something from the same cacheline instead. This was true
> for ECOBUS, but not for GTFIFODBG. Add posting reads on ECOBUS where
> GTFIFODBG was relied on.
> 
> In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
> well.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
> Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
> CC: Ben Widawsky <ben@bwidawsk.net>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Am I the only skeptic about what is actually fixing the bug here?
Without WC MMIO, the cacheline we readback from makes no difference.

ie. I put ECOBUS there for a warm and fuzzy feeling, nothing else.

> ---
>  drivers/gpu/drm/i915/intel_pm.c |   17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index abfff29..06b75a1 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4122,7 +4122,8 @@ static void __gen6_gt_force_wake_get(struct drm_i915_private *dev_priv)
>  static void __gen6_gt_force_wake_mt_reset(struct drm_i915_private *dev_priv)
>  {
>  	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(0xffff));
> -	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
> +	/* something from same cacheline, but !FORCEWAKE_MT */
> +	POSTING_READ(ECOBUS);
>  }
>  
>  static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
> @@ -4139,7 +4140,8 @@ static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
>  		DRM_ERROR("Timed out waiting for forcewake old ack to clear.\n");
>  
>  	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
> -	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
> +	/* something from same cacheline, but !FORCEWAKE_MT */
> +	POSTING_READ(ECOBUS);
>  
>  	if (wait_for_atomic((I915_READ_NOTRACE(forcewake_ack) & 1),
>  			    FORCEWAKE_ACK_TIMEOUT_MS))
> @@ -4176,14 +4178,16 @@ void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv)
>  static void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
>  {
>  	I915_WRITE_NOTRACE(FORCEWAKE, 0);
> -	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
> +	/* something from same cacheline, but !FORCEWAKE */
> +	POSTING_READ(ECOBUS);
>  	gen6_gt_check_fifodbg(dev_priv);
>  }
>  
>  static void __gen6_gt_force_wake_mt_put(struct drm_i915_private *dev_priv)
>  {
>  	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
> -	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
> +	/* something from same cacheline, but !FORCEWAKE_MT */
> +	POSTING_READ(ECOBUS);
>  	gen6_gt_check_fifodbg(dev_priv);
>  }
>  
> @@ -4223,6 +4227,8 @@ int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
>  static void vlv_force_wake_reset(struct drm_i915_private *dev_priv)
>  {
>  	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(0xffff));
> +	/* something from same cacheline, but !FORCEWAKE_VLV */
> +	POSTING_READ(FORCEWAKE_ACK_VLV);
>  }
>  
>  static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
> @@ -4243,7 +4249,8 @@ static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
>  static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
>  {
>  	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
> -	/* The below doubles as a POSTING_READ */
> +	/* something from same cacheline, but !FORCEWAKE_VLV */
> +	POSTING_READ(FORCEWAKE_ACK_VLV);
>  	gen6_gt_check_fifodbg(dev_priv);
>  }
>  
> -- 
> 1.7.9.5
> 

-- 
Ben Widawsky, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCH v2] drm/i915: fix FORCEWAKE posting reads
  2013-01-11 18:15 ` Ben Widawsky
@ 2013-01-17  8:24   ` Jani Nikula
  2013-01-17  9:42     ` Chris Wilson
  0 siblings, 1 reply; 6+ messages in thread
From: Jani Nikula @ 2013-01-17  8:24 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, Ben Widawsky, Alexander Bersenev

We stopped reading FORCEWAKE for posting reads in

commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

and started using something from the same cacheline instead. It turns out
reading ECOBUS as posting read worked fine, while GTFIFODBG did not,
preventing RC6 states after suspend/resume per the bug report referenced
below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near
the same cacheline or address range as FORCEWAKE.

Trying out various registers for posting reads showed that all tested
registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
work. Conversely, most (but not quite all) registers for which
NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
bug.

Based on the above, add posting reads on ECOBUS where GTFIFODBG was
previously relied on.

In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
address range as FORCEWAKE_VLV.

v2: Add more details to the commit message. No functional changes.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
CC: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index abfff29..06b75a1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4122,7 +4122,8 @@ static void __gen6_gt_force_wake_get(struct drm_i915_private *dev_priv)
 static void __gen6_gt_force_wake_mt_reset(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(0xffff));
-	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 }
 
 static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
@@ -4139,7 +4140,8 @@ static void __gen6_gt_force_wake_mt_get(struct drm_i915_private *dev_priv)
 		DRM_ERROR("Timed out waiting for forcewake old ack to clear.\n");
 
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));
-	POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 
 	if (wait_for_atomic((I915_READ_NOTRACE(forcewake_ack) & 1),
 			    FORCEWAKE_ACK_TIMEOUT_MS))
@@ -4176,14 +4178,16 @@ void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv)
 static void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE, 0);
-	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE */
+	POSTING_READ(ECOBUS);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
 static void __gen6_gt_force_wake_mt_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
-	/* gen6_gt_check_fifodbg doubles as the POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE_MT */
+	POSTING_READ(ECOBUS);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
@@ -4223,6 +4227,8 @@ int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 static void vlv_force_wake_reset(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(0xffff));
+	/* something from same cacheline, but !FORCEWAKE_VLV */
+	POSTING_READ(FORCEWAKE_ACK_VLV);
 }
 
 static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
@@ -4243,7 +4249,8 @@ static void vlv_force_wake_get(struct drm_i915_private *dev_priv)
 static void vlv_force_wake_put(struct drm_i915_private *dev_priv)
 {
 	I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL));
-	/* The below doubles as a POSTING_READ */
+	/* something from same cacheline, but !FORCEWAKE_VLV */
+	POSTING_READ(FORCEWAKE_ACK_VLV);
 	gen6_gt_check_fifodbg(dev_priv);
 }
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/i915: fix FORCEWAKE posting reads
  2013-01-17  8:24   ` [PATCH v2] " Jani Nikula
@ 2013-01-17  9:42     ` Chris Wilson
  2013-01-17 11:39       ` Jani Nikula
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2013-01-17  9:42 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, Ben Widawsky, Alexander Bersenev

On Thu, 17 Jan 2013 10:24:09 +0200, Jani Nikula <jani.nikula@intel.com> wrote:
> We stopped reading FORCEWAKE for posting reads in
> 
> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Sat Sep 1 22:59:50 2012 -0700
> 
>     drm/i915: Never read FORCEWAKE
> 
> and started using something from the same cacheline instead. It turns out
> reading ECOBUS as posting read worked fine, while GTFIFODBG did not,
> preventing RC6 states after suspend/resume per the bug report referenced
> below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near
> the same cacheline or address range as FORCEWAKE.
> 
> Trying out various registers for posting reads showed that all tested
> registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
> work. Conversely, most (but not quite all) registers for which
> NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
> bug.
> 
> Based on the above, add posting reads on ECOBUS where GTFIFODBG was
> previously relied on.
> 
> In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
> well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
> address range as FORCEWAKE_VLV.
> 
> v2: Add more details to the commit message. No functional changes.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
> Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
> CC: Ben Widawsky <ben@bwidawsk.net>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

You don't mention at all why you consider this to be important at all. A
hint that the extra read makes rc6 after resume more stable on one
machine would be useful.

So a missing flush of the write in _put() makes sense for rc6 staying
active. (If it happens once, it can happen everytime we do the forcewake
dance and so stay asserted indefinitely). And I can quite believe that
the hw has separate queues for the GT powerwell that require a read from
within that powerwell to flush, so the magic pixie dust looks consistent.

Ok, I'm happy that I can rationalise that this does indeed fix a genuine
quirk of our hw. The cargo cult survives.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/i915: fix FORCEWAKE posting reads
  2013-01-17  9:42     ` Chris Wilson
@ 2013-01-17 11:39       ` Jani Nikula
  2013-01-17 11:56         ` Daniel Vetter
  0 siblings, 1 reply; 6+ messages in thread
From: Jani Nikula @ 2013-01-17 11:39 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: Ben Widawsky, Alexander Bersenev

On Thu, 17 Jan 2013, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Thu, 17 Jan 2013 10:24:09 +0200, Jani Nikula <jani.nikula@intel.com> wrote:
>> We stopped reading FORCEWAKE for posting reads in
>> 
>> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
>> Author: Ben Widawsky <ben@bwidawsk.net>
>> Date:   Sat Sep 1 22:59:50 2012 -0700
>> 
>>     drm/i915: Never read FORCEWAKE
>> 
>> and started using something from the same cacheline instead. It turns out
>> reading ECOBUS as posting read worked fine, while GTFIFODBG did not,
>> preventing RC6 states after suspend/resume per the bug report referenced
>> below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near
>> the same cacheline or address range as FORCEWAKE.
>> 
>> Trying out various registers for posting reads showed that all tested
>> registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
>> work. Conversely, most (but not quite all) registers for which
>> NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
>> bug.
>> 
>> Based on the above, add posting reads on ECOBUS where GTFIFODBG was
>> previously relied on.
>> 
>> In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
>> well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
>> address range as FORCEWAKE_VLV.
>> 
>> v2: Add more details to the commit message. No functional changes.
>> 
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
>> Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
>> CC: Ben Widawsky <ben@bwidawsk.net>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> You don't mention at all why you consider this to be important at all. A
> hint that the extra read makes rc6 after resume more stable on one
> machine would be useful.
>
> So a missing flush of the write in _put() makes sense for rc6 staying
> active. (If it happens once, it can happen everytime we do the forcewake
> dance and so stay asserted indefinitely). And I can quite believe that
> the hw has separate queues for the GT powerwell that require a read from
> within that powerwell to flush, so the magic pixie dust looks consistent.
>
> Ok, I'm happy that I can rationalise that this does indeed fix a genuine
> quirk of our hw. The cargo cult survives.

Right, I just didn't feel very confident making strong claims here based
on more or less anecdotal evidence. (And even the original "never read
FORCEWAKE" feels like folklore...) Making rc6 more stable on one machine
was implied, but I could have been more explict about it. Perhaps Daniel
can amend the commit message from the above as he sees fit?

Thanks for the review.

BR,
Jani.

>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm/i915: fix FORCEWAKE posting reads
  2013-01-17 11:39       ` Jani Nikula
@ 2013-01-17 11:56         ` Daniel Vetter
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2013-01-17 11:56 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Alexander Bersenev, Ben Widawsky

On Thu, Jan 17, 2013 at 12:39 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> Right, I just didn't feel very confident making strong claims here based
> on more or less anecdotal evidence. (And even the original "never read
> FORCEWAKE" feels like folklore...) Making rc6 more stable on one machine
> was implied, but I could have been more explict about it. Perhaps Daniel
> can amend the commit message from the above as he sees fit?

Merged and amended slightly to make it clear that it fixes a
regression, and what the exact nature of the regression was. Also
added cc: stable. Thanks for patch and review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-17 11:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-11  7:53 [PATCH] drm/i915: fix FORCEWAKE posting reads Jani Nikula
2013-01-11 18:15 ` Ben Widawsky
2013-01-17  8:24   ` [PATCH v2] " Jani Nikula
2013-01-17  9:42     ` Chris Wilson
2013-01-17 11:39       ` Jani Nikula
2013-01-17 11:56         ` Daniel Vetter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).