| Message ID | 1358411049-1242-1-git-send-email-jani.nikula@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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); }
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(-)