drm/i915: Don't do posting reads on getting forcewake
The checking for ack and also any subsequent mmio access
will serialize with setting the forcewake bit. Drop the
posting read as superfluous.
Note that in the put side we still want to keep the posting read
as it will ensure that the hw sees our forcewake release in a
timely manner and doesn't keep the hw powered up.
Comment from Chris:
On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > IIRC the posting read from same cache line actually fixed real bugs. So
> > I'm a bit worried about dropping them. But I suppose it's possible only
> > the _put side was important for those bugs.
>
> I found these:
>
> commit
efc30424cbaf17c4e0293a33e6f1e8bbd50b49e0
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Thu Jul 26 16:24:50 2012 +0200
>
> drm/i915: fix forcewake related hangs on snb
>
> commit
da1a1ebe136b9a847997c5bd39caf6018bd0edb2
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date: Sat Sep 1 22:59:50 2012 -0700
>
> drm/i915: Never read FORCEWAKE
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51738
> https://bugs.freedesktop.org/show_bug.cgi?id=52424
>
> The snb here seems to survive gem_dummy_reloc_loop and
> gem_ring_sync_loop in here with the get side posting removed.
Note that we kept the once associated with #52424, but judging by my
comments in #51738 the posting read is just a band aid anyway as a full
mb() itself was not adequate.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: paste relevant review discussion in.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>