All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/18] drm/i915: After reset on sanitization, reset the engine backends
Date: Fri, 25 May 2018 16:25:16 +0300	[thread overview]
Message-ID: <877enr98ar.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <152725425845.11749.1258632701286396119@mail.alporthouse.com>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2018-05-25 14:13:19)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>> 
>> > As we reset the GPU on suspend/resume, we also do need to reset the
>> > engine state tracking so call into the engine backends. This is
>> > especially important so that we can also sanitize the state tracking
>> > across resume.
>> >
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > ---
>> >  drivers/gpu/drm/i915/i915_gem.c | 24 ++++++++++++++++++++++++
>> >  1 file changed, 24 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> > index 7b5544efa0ba..5a7e0b388ad0 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > @@ -4955,7 +4955,22 @@ static void assert_kernel_context_is_current(struct drm_i915_private *i915)
>> >  
>> >  void i915_gem_sanitize(struct drm_i915_private *i915)
>> >  {
>> > +     struct intel_engine_cs *engine;
>> > +     enum intel_engine_id id;
>> > +
>> > +     GEM_TRACE("\n");
>> > +
>> >       mutex_lock(&i915->drm.struct_mutex);
>> > +
>> > +     intel_runtime_pm_get(i915);
>> > +     intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
>> > +
>> > +     /*
>> > +      * As we have just resumed the machine and woken the device up from
>> > +      * deep PCI sleep (presumably D3_cold), assume the HW has been reset
>> > +      * back to defaults, recovering from whatever wedged state we left it
>> > +      * in and so worth trying to use the device once more.
>> > +      */
>> >       if (i915_terminally_wedged(&i915->gpu_error))
>> >               i915_gem_unset_wedged(i915);
>> >  
>> > @@ -4970,6 +4985,15 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
>> >       if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
>> >               WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
>> >  
>> > +     /* Reset the submission backend after resume as well as the GPU reset */
>> > +     for_each_engine(engine, i915, id) {
>> > +             if (engine->reset.reset)
>> > +                     engine->reset.reset(engine, NULL);
>> > +     }
>> 
>> The NULL guarantees that it wont try to do any funny things
>> with the incomplete state.
>
> The NULL is there because this gets called really, really early before
> we've finished setting up the engines.
>
>> But what guarantees the the timeline cleanup so that
>> we don't endup unwinding incomplete requests crap?
>
> To get here we must have gone through at least the start of a suspend.
> So we've already cleaned everything up; nicely or forcefully though a
> wedge. Whatever is here is garbage, including any internal knowledge in
> the backend about what state we left the machine in.

Fair enough,

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-25 13:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-25  9:31 RFC avoiding ksoftirqd for first submission Chris Wilson
2018-05-25  9:31 ` [PATCH 01/18] drm/i915: Prepare GEM for suspend earlier Chris Wilson
2018-05-25 12:56   ` Mika Kuoppala
2018-05-25  9:31 ` [PATCH 02/18] drm/i915: Switch to kernel context before idling at runtime Chris Wilson
2018-05-25 13:44   ` Mika Kuoppala
2018-05-25  9:31 ` [PATCH 03/18] drm/i915: "Race-to-idle" after switching to the kernel context Chris Wilson
2018-05-25 12:22   ` Mika Kuoppala
2018-05-25 12:26     ` Chris Wilson
2018-05-25  9:31 ` [PATCH 04/18] drm/i915: After reset on sanitization, reset the engine backends Chris Wilson
2018-05-25 13:13   ` Mika Kuoppala
2018-05-25 13:17     ` Chris Wilson
2018-05-25 13:25       ` Mika Kuoppala [this message]
2018-05-25  9:31 ` [PATCH 05/18] drm/i915: Only sanitize GEM from late suspend Chris Wilson
2018-05-25  9:31 ` [PATCH 06/18] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset Chris Wilson
2018-05-25  9:31 ` [PATCH 07/18] drm/i915: Be irqsafe inside reset Chris Wilson
2018-05-25  9:31 ` [PATCH 08/18] drm/i915/execlists: Wait for ELSP submission on restart Chris Wilson
2018-05-25 12:37   ` Mika Kuoppala
2018-05-25  9:31 ` [PATCH 09/18] drm/i915/execlists: Reset the CSB head tracking on reset/sanitization Chris Wilson
2018-05-25  9:31 ` [PATCH 10/18] drm/i915/execlists: Pull submit after dequeue under timeline lock Chris Wilson
2018-05-25  9:31 ` [PATCH 11/18] drm/i915/execlists: Pull CSB reset under the timeline.lock Chris Wilson
2018-05-25  9:32 ` [PATCH 12/18] drm/i915/execlists: Process one CSB interrupt at a time Chris Wilson
2018-05-25  9:32 ` [PATCH 13/18] drm/i915/execlists: Unify CSB access pointers Chris Wilson
2018-05-25  9:32 ` [PATCH 14/18] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) Chris Wilson
2018-05-25  9:32 ` [PATCH 15/18] drm/i915: Move rate-limiting request retire to after submission Chris Wilson
2018-05-25  9:32 ` [PATCH 16/18] drm/i915: Wait for engines to idle before retiring Chris Wilson
2018-05-25  9:32 ` [PATCH 17/18] drm/i915: Move engine request retirement to intel_engine_cs Chris Wilson
2018-05-25  9:32 ` [PATCH 18/18] drm/i915: Hold request reference for submission until retirement Chris Wilson
2018-05-25  9:55 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/18] drm/i915: Prepare GEM for suspend earlier Patchwork
2018-05-25 10:00 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-25 10:16 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-25 14:25 ` ✗ Fi.CI.IGT: failure " 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=877enr98ar.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.