From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect
Date: Fri, 02 Mar 2018 17:50:53 +0200 [thread overview]
Message-ID: <87efl2pjc2.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20180302143246.2579-4-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> During reset/wedging, we have to clean up the requests on the timeline
> and flush the pending interrupt state. Currently, we are abusing the irq
> disabling of the timeline spinlock to protect the irq state in
> conjunction to the engine's timeline requests, but this is accidental
> and conflates the spinlock with the irq state. A baffling state of
> affairs for the reader.
>
> Instead, explicitly disable irqs over the critical section, and separate
> modifying the irq state from the timeline's requests.
>
> Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 0482e54c94f0..7d1109aceabb 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct intel_engine_cs *engine)
>
> GEM_TRACE("%s\n", engine->name);
>
> - spin_lock_irqsave(&engine->timeline->lock, flags);
> + local_irq_save(flags);
Chris explained in irc that this is for lockdep only. It was a bit
confusing as we already are guaranteed exclusive access to
state by tasklet being killed and dead at this point.
I think this warrants a comment that this is to soothe lockdep.
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> execlists_cancel_port_requests(execlists);
>
> + spin_lock(&engine->timeline->lock);
> +
> /* Mark all executing requests as skipped. */
> list_for_each_entry(rq, &engine->timeline->requests, link) {
> GEM_BUG_ON(!rq->global_seqno);
> @@ -727,6 +729,8 @@ static void execlists_cancel_requests(struct intel_engine_cs *engine)
> execlists->first = NULL;
> GEM_BUG_ON(port_isset(execlists->port));
>
> + spin_unlock(&engine->timeline->lock);
> +
> /*
> * The port is checked prior to scheduling a tasklet, but
> * just in case we have suspended the tasklet to do the
> @@ -738,7 +742,7 @@ static void execlists_cancel_requests(struct intel_engine_cs *engine)
> /* Mark all CS interrupts as complete */
> execlists->active = 0;
>
> - spin_unlock_irqrestore(&engine->timeline->lock, flags);
> + local_irq_restore(flags);
> }
>
> /*
> @@ -1618,10 +1622,11 @@ static void reset_common_ring(struct intel_engine_cs *engine,
> GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>
> - spin_lock_irqsave(&engine->timeline->lock, flags);
> + local_irq_save(flags);
>
> reset_irq(engine);
>
> +
Unintentional extra line?
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> /*
> * Catch up with any missed context-switch interrupts.
> *
> @@ -1634,14 +1639,17 @@ static void reset_common_ring(struct intel_engine_cs *engine,
> execlists_cancel_port_requests(execlists);
>
> /* Push back any incomplete requests for replay after the reset. */
> + spin_lock(&engine->timeline->lock);
> __unwind_incomplete_requests(engine);
> + spin_unlock(&engine->timeline->lock);
>
> /* Mark all CS interrupts as complete */
> execlists->active = 0;
>
> - spin_unlock_irqrestore(&engine->timeline->lock, flags);
> + local_irq_restore(flags);
>
> - /* If the request was innocent, we leave the request in the ELSP
> + /*
> + * If the request was innocent, we leave the request in the ELSP
> * and will try to replay it on restarting. The context image may
> * have been corrupted by the reset, in which case we may have
> * to service a new GPU hang, but more likely we can continue on
> @@ -1654,7 +1662,8 @@ static void reset_common_ring(struct intel_engine_cs *engine,
> if (!request || request->fence.error != -EIO)
> return;
>
> - /* We want a simple context + ring to execute the breadcrumb update.
> + /*
> + * We want a simple context + ring to execute the breadcrumb update.
> * We cannot rely on the context being intact across the GPU hang,
> * so clear it and rebuild just what we need for the breadcrumb.
> * All pending requests for this context will be zapped, and any
> --
> 2.16.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-02 15:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 14:32 [PATCH 1/5] drm/i915: Stop engines around GPU reset preparations Chris Wilson
2018-03-02 14:32 ` [PATCH 2/5] drm/i915: Suspend submission tasklets around wedging Chris Wilson
2018-03-02 14:34 ` Mika Kuoppala
2018-03-02 14:32 ` [PATCH 3/5] drm/i915/execlists: Move irq state manipulation inside irq disabled region Chris Wilson
2018-03-02 14:32 ` [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect Chris Wilson
2018-03-02 15:50 ` Mika Kuoppala [this message]
2018-03-02 16:04 ` Chris Wilson
2018-03-02 16:11 ` Mika Kuoppala
2018-03-02 14:32 ` [PATCH 5/5] drm/i915: Call prepare/finish around intel_gpu_reset() during GEM sanitize Chris Wilson
2018-03-02 15:51 ` Mika Kuoppala
2018-03-02 15:43 ` ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Stop engines around GPU reset preparations Patchwork
2018-03-02 18:10 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-03-03 8:46 ` [PATCH 1/5] " 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=87efl2pjc2.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.