Patch "drm/i915/gt: Reset twice" has been added to the 5.10-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    drm/i915/gt: Reset twice

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-i915-gt-reset-twice.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 3d0246017a00d063299130a38f1b8207af40f6e3
Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date:   Mon Dec 12 17:13:38 2022 +0100

    drm/i915/gt: Reset twice
    
    [ Upstream commit d3de5616d36462a646f5b360ba82d3b09ff668eb ]
    
    After applying an engine reset, on some platforms like Jasperlake, we
    occasionally detect that the engine state is not cleared until shortly
    after the resume. As we try to resume the engine with volatile internal
    state, the first request fails with a spurious CS event (it looks like
    it reports a lite-restore to the hung context, instead of the expected
    idle->active context switch).
    
    Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx
    Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
    Signed-off-by: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
    Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@xxxxxxxxx>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221212161338.1007659-1-andi.shyti@xxxxxxxxxxxxxxx
    (cherry picked from commit 3db9d590557da3aa2c952f2fecd3e9b703dad790)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
index ac36b67fb46b..00b5912a88b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -289,6 +289,7 @@ static int ilk_do_reset(struct intel_gt *gt, intel_engine_mask_t engine_mask,
 static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
 {
 	struct intel_uncore *uncore = gt->uncore;
+	int loops = 2;
 	int err;
 
 	/*
@@ -296,18 +297,39 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
 	 * for fifo space for the write or forcewake the chip for
 	 * the read
 	 */
-	intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
+	do {
+		intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
 
-	/* Wait for the device to ack the reset requests */
-	err = __intel_wait_for_register_fw(uncore,
-					   GEN6_GDRST, hw_domain_mask, 0,
-					   500, 0,
-					   NULL);
+		/*
+		 * Wait for the device to ack the reset requests.
+		 *
+		 * On some platforms, e.g. Jasperlake, we see that the
+		 * engine register state is not cleared until shortly after
+		 * GDRST reports completion, causing a failure as we try
+		 * to immediately resume while the internal state is still
+		 * in flux. If we immediately repeat the reset, the second
+		 * reset appears to serialise with the first, and since
+		 * it is a no-op, the registers should retain their reset
+		 * value. However, there is still a concern that upon
+		 * leaving the second reset, the internal engine state
+		 * is still in flux and not ready for resuming.
+		 */
+		err = __intel_wait_for_register_fw(uncore, GEN6_GDRST,
+						   hw_domain_mask, 0,
+						   2000, 0,
+						   NULL);
+	} while (err == 0 && --loops);
 	if (err)
 		drm_dbg(&gt->i915->drm,
 			"Wait for 0x%08x engines reset failed\n",
 			hw_domain_mask);
 
+	/*
+	 * As we have observed that the engine state is still volatile
+	 * after GDRST is acked, impose a small delay to let everything settle.
+	 */
+	udelay(50);
+
 	return err;
 }