[CI v1 2/4] drm/i915/guc: Holdoff context destruction when CT's aren't enabled

[Alan Previn]

During suspend, we flush pending workers including the context
destruction. We don't expect new guc submissions to get
triggered as we idled the GPU. However, we have observed
very late sw fences (for FENCE_FREE which leads to this worker)
getting triggered from outside i915. Additionally, in resume,
its possible similar type of sw fences that didn't get a chance
to close during suspend may get its time during resume.

In this case, when we get a request to destroy a context but
GuC's CTs are not enabled, let't just skip it, leaving the
context on the destroy list to be picked up the next time
the worker is invoked.

NOTE: If the GuC is wedged / reset / re-sanitized after this
skipping, that's also okay since the destroy list would be purged.

Signed-off-by: Alan Previn <alan.previn.teres.alexis at intel.com>
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index dc7735a19a5a..087630a8efbb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3281,6 +3281,14 @@ static void destroyed_worker_func(struct work_struct *w)
 	struct intel_gt *gt = guc_to_gt(guc);
 	int tmp;
 
+	/*
+	 * Assuming we are here because a context free fence signal came very late
+	 * in suspend flow or very early in resume flows, just skipping it is fine
+	 * it can be picked up later on the next event
+	 */
+	if (!guc->ct.enabled)
+		return;
+
 	with_intel_gt_pm(gt, tmp)
 		deregister_destroyed_contexts(guc);
 }
-- 
2.39.0