[Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region

[Chris Wilson]

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 at linux.intel.com>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> Cc: Michel Thierry <michel.thierry at intel.com>
> ---
>  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