• Mika Kuoppala's avatar
    drm/i915: Don't do posting reads on getting forcewake · 07859504
    Mika Kuoppala authored
    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 6af2d180
    > 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 8dee3eea
    > 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: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
    Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    [danvet: paste relevant review discussion in.]
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    07859504
intel_uncore.c 37.1 KB