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ł
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
