All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend
Date: Thu, 11 Feb 2021 08:57:45 +0000	[thread overview]
Message-ID: <161303386546.13035.3606386396573664382@build.alporthouse.com> (raw)
In-Reply-To: <20210211042517.GJ82362@intel.com>

Quoting Rodrigo Vivi (2021-02-11 04:25:17)
> On Wed, Feb 10, 2021 at 10:19:50PM +0000, Chris Wilson wrote:
> > After calling intel_gt_suspend_prepare(), the driver starts to turn off
> > various subsystems, such as clearing the GGTT, before calling
> > intel_gt_suspend_late() to relinquish control over the GT. However, if
> > we still have internal GPU state active as we clear the GGTT, the GPU
> > may write back its internal state to the residual GGTT addresses that
> > are now pointing into scratch. Let's reset the GPU to clear that
> > internal state as soon we have idled the GPU in prepare-to-suspend.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > index 0bd303d2823e..f41612faa269 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > @@ -295,6 +295,9 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
> >       wait_for_suspend(gt);
> 
> you just wedged the gpu here...

Potentially. As a means to clear a stuck GPU and force it to idle.
 
> >       intel_uc_suspend(&gt->uc);
> > +
> > +     /* Flush all the contexts and internal state before turning off GGTT */
> > +     gt_sanitize(gt, false);
> 
> and now we are unsetting wedge here...
> 
> is this right?

But irrelevant, since it is undone on any of the resume pathways which
must be taken by this point.

Resume has been for many years the method to unwedge a GPU; with the
presumption being that the intervening PCI level reset would be enough
to recover the GPU. Otherwise, it would presumably quite quickly go back
into the wedged state.

The wedging on suspend is just there to cancel outstanding work. Which
is not what we want (we just want to remove work), but is what we have
for the moment. The sanitize is to make sure we don't leak our state
beyond our control of the HW.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-02-11  8:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10 22:19 [Intel-gfx] [PATCH 1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend Chris Wilson
2021-02-10 22:19 ` [Intel-gfx] [PATCH 2/6] drm/i915: Clear internal GT state on hibernate Chris Wilson
2021-02-11  4:28   ` Rodrigo Vivi
2021-02-11  8:46     ` Chris Wilson
2021-02-10 22:19 ` [Intel-gfx] [PATCH 3/6] drm/i915/selftests: Declare suspend_state before testing suspend Chris Wilson
2021-02-10 22:19 ` [Intel-gfx] [PATCH 4/6] drm/i915/selftests: Restrict partial-tiling to write into the object Chris Wilson
2021-02-10 22:19 ` [Intel-gfx] [PATCH 5/6] drm/i915: Check for scratch page scribbling Chris Wilson
2021-02-10 22:19 ` [Intel-gfx] [PATCH 6/6] drm/i915: Remove unused debug functions Chris Wilson
2021-02-10 23:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend Patchwork
2021-02-10 23:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-02-11  4:25 ` [Intel-gfx] [PATCH 1/6] " Rodrigo Vivi
2021-02-11  8:57   ` Chris Wilson [this message]
2021-02-11 13:09 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] " Patchwork

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=161303386546.13035.3606386396573664382@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    /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.