Quoting Michał Winiarski (2017-10-19 19:36:17)
> @@ -686,10 +802,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) {
> + execlists_cancel_port_requests(&engine->execlists);
> +
> + spin_lock_irq(&engine->timeline->lock);
> + execlists_unwind_incomplete_requests(execlists);
> + 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);
> + }
> +
> rq = port_request(&port[0]);
> while (rq && i915_gem_request_completed(rq)) {
> trace_i915_gem_request_out(rq);
I don't think we have the ordering right here for
cancel_port_requests(). It should only be called for what are
effectively incomplete requests, or else the
INTEL_CONTEXT_SCHEDULE_PREEMPTED is a misnomer. It doesn't look like it
makes any great difference in the over scheme of things, but I'm tempted
to put a GEM_BUG_ON(i915_gem_request_completed(rq)) there.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
