]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915/execlists: Move reset_active() from schedule-out to schedule-in
authorChris Wilson <chris@chris-wilson.co.uk>
Mon, 11 Nov 2019 13:32:05 +0000 (13:32 +0000)
committerChris Wilson <chris@chris-wilson.co.uk>
Mon, 11 Nov 2019 16:37:05 +0000 (16:37 +0000)
commit31b61f0ef9af62b6404d8df5dcd2cf58f80c9f53
tree1e68e9a32bb7b27d9847d04f8ac7cb69af60b338
parentd323c9b88260bc2cf3e3ed4bc741ab69643e0233
drm/i915/execlists: Move reset_active() from schedule-out to schedule-in

The gem_ctx_persistence/smoketest was detecting an odd coherency issue
inside the LRC context image; that the address of the ring buffer did
not match our associated struct intel_ring. As we set the address into
the context image when we pin the ring buffer into place before the
context is active, that leaves the question of where did it get
overwritten. Either the HW context save occurred after our pin which
would imply that our idle barriers are broken, or we overwrote the
context image ourselves. It is only in reset_active() where we dabble
inside the context image outside of a serialised path from schedule-out;
but we could equally perform the operation inside schedule-in which is
then fully serialised with the context pin -- and remains serialised by
the engine pulse with kill_context(). (The only downside, aside from
doing more work inside the engine->active.lock, was the plan to merge
all the reset paths into doing their context scrubbing on schedule-out
needs more thought.)

Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on schedule-out")
Testcase: igt/gem_ctx_persistence/smoketest
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/gt/intel_lrc.c