From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>,
intel-gfx@lists.freedesktop.org,
Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: Flush the PTEs after updating them before suspend
Date: Tue, 23 Sep 2014 14:55:26 +0300 [thread overview]
Message-ID: <87wq8u5z69.fsf@intel.com> (raw)
In-Reply-To: <20140918115215.GN31703@phenom.ffwll.local>
On Thu, 18 Sep 2014, Daniel Vetter <daniel@ffwll.ch> 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@intel.com
>> Signed-off-by: Chris Wilson <chris@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@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@gmail.com>
> Cc: stable@vger.kernel.org
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Todd Previte <tprevite@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
>
> Cc: stable@vger.kernel.org
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Todd Previte <tprevite@gmail.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Daniel Vetter <daniel.vetter@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.
The patch fails to apply on any branch. Please refresh.
BR,
Jani.
>
> 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.
> -Daniel
>
>
>> ---
>> drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 97ba18846761..aa81b217fac0 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -1234,6 +1234,16 @@ void i915_check_and_clear_faults(struct drm_device *dev)
>> POSTING_READ(RING_FAULT_REG(RCS_ENGINE(dev_priv)));
>> }
>>
>> +static void i915_ggtt_flush(struct drm_i915_private *dev_priv)
>> +{
>> + if (INTEL_INFO(dev_priv)->gen < 6) {
>> + intel_gtt_chipset_flush();
>> + } else {
>> + I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
>> + POSTING_READ(GFX_FLSH_CNTL_GEN6);
>> + }
>> +}
>> +
>> void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
>> {
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> @@ -1250,6 +1260,8 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
>> dev_priv->gtt.base.start,
>> dev_priv->gtt.base.total,
>> true);
>> +
>> + i915_ggtt_flush(dev_priv);
>> }
>>
>> void i915_gem_restore_gtt_mappings(struct drm_device *dev)
>> @@ -1302,7 +1314,7 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
>> gen6_write_pdes(container_of(vm, struct i915_hw_ppgtt, base));
>> }
>>
>> - i915_gem_chipset_flush(dev);
>> + i915_ggtt_flush(dev_priv);
>> }
>>
>> int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
>> --
>> 2.1.0
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-09-23 11:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 6:03 [PATCH] drm/i915: Flush the PTEs after updating them before suspend Chris Wilson
2014-09-18 11:52 ` Daniel Vetter
2014-09-23 11:55 ` Jani Nikula [this message]
2014-09-25 8:44 ` Chris Wilson
2014-09-25 9:13 ` Chris Wilson
2014-09-29 12:26 ` Daniel Vetter
2014-09-29 13:20 ` Jani Nikula
2014-09-29 13:20 ` Jani Nikula
2014-09-25 8:40 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wq8u5z69.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.