Quoting Chris Wilson (2018-03-02 13:12:46)
> Although this state (execlists->active and engine->irq_posted) itself is
> not protected by the engine->timeline spinlock, it does conveniently
> ensure that irqs are disabled. We can use this to protect our
> manipulation of the state and so ensure that the next IRQ to arrive sees
> consistent state and (hopefully) ignores the reset engine.
>
> Suggested-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Cc: Michel Thierry <michel.thierry@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index c1a3636e94fc..0482e54c94f0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs *engine,
> GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>
> - reset_irq(engine);
> -
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> + reset_irq(engine);
Alternatively, we split this up with
local_irq_save(flags);
reset_irq(engine);
spin_lock(&engine->timline->lock);
...
Worth the exercise?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
