[Intel-gfx] [PATCH] drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines

[Chris Wilson]

Quoting Andi Shyti (2019-09-29 21:25:54)
> Hi Chris,
> 
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1186,6 +1186,21 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
> >       /* we need to manually load the submit queue */
> >       if (execlists->ctrl_reg)
> >               writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> > +
> > +     /*
> > +      * Now this is evil magic.
> > +      *
> > +      * Adding the same udelay() to process_csb before we clear
> > +      * execlists->pending (that is after we receive the HW ack for this
> > +      * submit and before we can submit again) does not relieve the symptoms
> > +      * (machine lockup). So is the active difference here the wait under
> > +      * the irq-off spinlock? That gives more credance to the theory that
> > +      * the issue is interrupt delivery. Also note that we still rely on
> > +      * disabling RPS, again that seems like an issue with simultaneous
> > +      * GT interrupts being delivered to the same CPU.
> > +      */
> > +     if (IS_TIGERLAKE(engine->i915))
> > +             udelay(250);
> 
> you want a delay of 250us. Two questions:
> 
> 1. why 250?

Magic. Purely first random number.

> 2. is there any good reason for using 'udelay' for sleeping 250us
>    (that is quite a long time) and not 'usleep'?

We are inside interrupt context. That this trick worked much better
inside interrupt context than out makes me suspect interrupt delivery so
much more.
-Chris