My current theory is that this masks interrupt delivery to the local CPU
during a critical phase. Purely papering over the symptoms with a delay
plucked out of thin air from testing on tgl1-gem, refined slightly by
just waiting for the next ack (though technically the next CS event may
not be the corresponding event for this submit, but an intermediate
completion).
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
Cc: Andi Shyti <andi.sh...@intel.com>
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab725a6ca0ac..35410d647b52 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1155,6 +1155,7 @@ assert_pending_valid(const struct intel_engine_execlists
*execlists,
static void execlists_submit_ports(struct intel_engine_cs *engine)
{
struct intel_engine_execlists *execlists = &engine->execlists;
+ unsigned int tail = READ_ONCE(*execlists->csb_write);
unsigned int n;
GEM_BUG_ON(!assert_pending_valid(execlists, "submit"));
@@ -1186,6 +1187,14 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
/* we need to manually load the submit queue */
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
+
+ if (IS_TIGERLAKE(engine->i915)) {
+ u64 start = local_clock();
+ do
+ cpu_relax();
+ while (tail == READ_ONCE(*execlists->csb_write) &&
+ (local_clock() - start) >> 20 == 0);
+ }
}
static bool ctx_single_port_submission(const struct intel_context *ce)
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
