[Saucy][SRU][PATCH]drm/i915: Disable GGTT PTEs on GEN6+ suspend

Zhang, Xiong Y xiong.y.zhang at intel.com
Wed Dec 25 09:03:09 UTC 2013


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

    Once the machine gets to a certain point in the suspend process, we
    expect the GPU to be idle. If it is not, we might corrupt memory.
    Empirically (with an early version of this patch) we have seen this is
    not the case. We cannot currently explain why the latent GPU writes
    occur.

    In the technical sense, this patch is a workaround in that we have an
    issue we can't explain, and the patch indirectly solves the issue.
    However, it's really better than a workaround because we understand why
    it works, and it really should be a safe thing to do in all cases.

    The noticeable effect other than the debug messages would be an increase
    in the suspend time. I have not measure how expensive it actually is.

    I think it would be good to spend further time to root cause why we're
    seeing these latent writes, but it shouldn't preclude preventing the
    fallout.

    NOTE: It should be safe (and makes some sense IMO) to also keep the
    VALID bit unset on resume when we clear_range(). I've opted not to do
    this as properly clearing those bits at some later point would be extra
    work.

    v2: Fix bugzilla link

    Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
    Tested-by: Takashi Iwai <tiwai at suse.de>
    Tested-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
    Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
    Tested-By: Todd Previte <tprevite at gmail.com>
    Cc: stable at vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20131225/08a6cc72/attachment.html>


More information about the kernel-team mailing list