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