All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/gt: Only unwedge if we can reset first
Date: Fri, 13 Sep 2019 17:13:46 +0100	[thread overview]
Message-ID: <156839122631.18832.11616206837543268861@skylake-alporthouse-com> (raw)
In-Reply-To: <20190913160334.GC1208@intel.com>

Quoting Ville Syrjälä (2019-09-13 17:03:34)
> On Fri, Sep 13, 2019 at 08:47:20AM +0100, Chris Wilson wrote:
> > Unwedging the GPU requires a successful GPU reset before we restore the
> > default submission, or else we may see residual context switch events
> > that we were not expecting.
> > 
> > v2: Pull in the special-case reset_clobbers_display, and explain why it
> > should be safe in the context of unwedging.
> > 
> > Reported-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > ---
> >  drivers/gpu/drm/i915/gt/intel_reset.c | 30 ++++++++++++++++++++++++++-
> >  1 file changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> > index ee52947eb31d..d3b1cdafd4c2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > @@ -7,6 +7,7 @@
> >  #include <linux/sched/mm.h>
> >  #include <linux/stop_machine.h>
> >  
> > +#include "display/intel_display.h"
> >  #include "display/intel_display_types.h"
> >  #include "display/intel_overlay.h"
> >  
> > @@ -729,6 +730,28 @@ static void nop_submit_request(struct i915_request *request)
> >       intel_engine_queue_breadcrumbs(engine);
> >  }
> >  
> > +static bool reset_clobbers_display(struct drm_i915_private *i915)
> > +{
> > +     struct intel_crtc *crtc;
> > +
> > +     if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
> > +             return false;
> > +
> > +     /*
> > +      * While this appears racy, we should only be inspecting the display
> > +      * state at runtime from inside a GPU reset, which will be serialized
> > +      * with modesets on affected machines. For a full device reset,
> > +      * we should already have cleared the active CRTC state in
> > +      * intel_prepare_reset().
> > +      */
> > +     for_each_intel_crtc(&i915->drm, crtc) {
> > +             if (crtc->active)
> > +                     return true;
> > +     }
> > +
> > +     return false;
> > +}
> > +
> >  static void __intel_gt_set_wedged(struct intel_gt *gt)
> >  {
> >       struct intel_engine_cs *engine;
> > @@ -793,6 +816,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
> >       struct intel_gt_timelines *timelines = &gt->timelines;
> >       struct intel_timeline *tl;
> >       unsigned long flags;
> > +     bool ok;
> >  
> >       if (!test_bit(I915_WEDGED, &gt->reset.flags))
> >               return true;
> > @@ -838,7 +862,11 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
> >       }
> >       spin_unlock_irqrestore(&timelines->lock, flags);
> >  
> > -     intel_gt_sanitize(gt, false);
> > +     ok = false;
> > +     if (!reset_clobbers_display(gt->i915))
> > +             ok = __intel_gt_reset(gt, ALL_ENGINES) == 0;
> 
> /me re-reading a lot of the reset code..
> 
> I'm rather confused about the whole reset flow. We now do a reset here,
> but then we still do another one later on? Except for i915_gem_sanitize(),
> which gets called during probe and resume so only does the single reset
> I guess.

The idea was to keep wedging as a separate process (since that gives
nice symmetry because set-wedge unset-wedge). We can merge it so
that we only do the single reset, but we still should keep the request
flushing in place, or we need to play games with rcu barriers again.
 
> Hopefully we can't be marked as wedged during probe because I think
> this gets called before crtc->active is populated so we'd just do the
> reset anyway.

I was hoping the crtcs would be off at that point... They weren't.

> As for the resume cases, I think the display should be off already
> when this gets called.
> 
> So I guess I'm not really sure what this check is meant to do for us.

I gave up,

-       intel_gt_sanitize(gt, false);
+       /* We must reset pending GPU events before restoring our submission */
+       ok = !HAS_EXECLISTS(gt->i915);
+       if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display)
+               ok = __intel_gt_reset(gt, ALL_ENGINES) == 0;
+       if (!ok)
+               return false;

-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-09-13 16:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13  7:47 [PATCH] drm/i915/gt: Only unwedge if we can reset first Chris Wilson
2019-09-13  9:35 ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-09-13 10:06   ` Chris Wilson
2019-09-13 16:03 ` [PATCH] " Ville Syrjälä
2019-09-13 16:13   ` Chris Wilson [this message]
2019-09-27 16:03 Chris Wilson
2019-10-01  8:23 ` Janusz Krzysztofik

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=156839122631.18832.11616206837543268861@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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.