[Intel-gfx] [PATCH] drm/i915: Flush the PTEs after updating them before suspend

Chris Wilson chris at chris-wilson.co.uk
Thu Sep 25 10:40:59 CEST 2014


On Thu, Sep 18, 2014 at 01:52:15PM +0200, Daniel Vetter wrote:
> On Thu, Sep 18, 2014 at 07:03:32AM +0100, Chris Wilson wrote:
> > As we use WC updates of the PTE, we are responsible for notifying the
> > hardware when to flush its TLBs. Do so after we zap all the PTEs before
> > suspend (and the BIOS tries to read our GTT).
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
> > Tested-by: ming.yao at intel.com
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> This fixes a regression from the (functional) revert
> 
>     drm/i915: Undo gtt scratch pte unmapping again
> 
>     It apparently blows up on some machines. This functionally reverts
> 
>     commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
>     Author: Ben Widawsky <benjamin.widawsky at intel.com>
>     Date:   Wed Oct 16 09:21:30 2013 -0700
> 
>         drm/i915: Disable GGTT PTEs on GEN6+ suspend
> 
>     Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841
>     Reported-and-Tested-by: Brad  Jackson <bjackson0971 at gmail.com>
>     Cc: stable at vger.kernel.org
>     Cc: Takashi Iwai <tiwai at suse.de>
>     Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
>     Cc: Todd Previte <tprevite at gmail.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>     Signed-off-by: Dave Airlie <airlied at redhat.com>
> 
> Cc: stable at vger.kernel.org
> Cc: Takashi Iwai <tiwai at suse.de>
> Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Cc: Todd Previte <tprevite at gmail.com>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> When fixing regressions pls don't forget to cite the offending commit and
> cc all relevant people. Jani, please amend the commit with the above when
> merging.

I disagree that is the regression it is fixing, it is just band-aids all
the way down. This patch fixes a bug present in the earlier patch.
 
> Aside: This means that the bios writes to various ranges in the gtt, so I
> still think we need to insert ptes pointing at stolen, too. Otherwise
> we've simply reduced the chances for this bug to destroy important
> something I think.

Yup, the BIOS touching hardware it no longer has exclusive access to is
fundamentally broken.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list