[Intel-gfx] [PATCH 09/10] drm/i915/guc: Preemption! With GuC.

[Michał Winiarski]

On Thu, Oct 05, 2017 at 10:31:34AM +0000, Chris Wilson wrote:
> Quoting Michał Winiarski (2017-10-05 10:20:04)
> > @@ -625,10 +723,23 @@ static void i915_guc_irq_handler(unsigned long data)
> >         struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
> >         struct intel_engine_execlists * const execlists = &engine->execlists;
> >         struct execlist_port *port = execlists->port;
> > -       const struct execlist_port * const last_port =
> > -               &execlists->port[execlists->port_mask];
> >         struct drm_i915_gem_request *rq;
> >  
> > +       if (READ_ONCE(execlists->preempt) &&
> > +           intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
> > +           GUC_PREEMPT_FINISHED) {
> > +               execlist_cancel_port_requests(&engine->execlists);
> > +
> > +               spin_lock_irq(&engine->timeline->lock);
> > +               unwind_incomplete_requests(engine);
> > +               spin_unlock_irq(&engine->timeline->lock);
> > +
> > +               wait_for_guc_preempt_report(engine);
> > +
> > +               WRITE_ONCE(execlists->preempt, false);
> > +               intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
> 
> Ok. So we injected the preempt context, observed it complete. What stops
> the GuC from switching back to the normal context and draining its wq?
> (Those requests we've just put back to be re-executed later.)
> -Chris

We're sending GuC action with:
INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q | INTEL_GUC_PREEMPT_OPTION_DROP_SUBMIT_Q

Which prevents GuC from doing exactly that.

I'll add a comment in inject preempt ctx.

-Michał