[PATCH i-g-t] tests/intel/kms_dp_linktrain_fallback: Clear stale forced LT failure counter on timeout

[Kunal Joshi <kunal1.joshi@intel.com>]

When force_failure_and_wait() sets force_train_failure=2 (LT_FAILURE_REDUCED_CAPS)
and triggers a retrain, the kernel consumes the counter once per
intel_dp_link_train() call. With MAX_SEQ_TRAIN_FAILURES=2, the first call
happens inside the modeset triggered by force_retrain. The second consumption
depends on a queued link_check_work (delay=0) firing and completing a second
modeset promptly.

However, on external DP connectors (where this test runs), the second
intel_dp_link_train() call can fail to execute if:

 - A long HPD fires between the two retrains (common on marginal links,
   USB-C docks, TBT connections). The long HPD handler sets
   reset_link_params=true, which triggers intel_dp_reset_link_params()
   during detect -- resetting seq_train_failures to 0. When the queued
   link_check_work then calls intel_dp_needs_link_retrain(), it sees
   seq_train_failures==0, link status OK, and returns false. No second
   retrain occurs.

 - The second retrain's intel_modeset_commit_pipes() fails due to lock
   contention with a concurrent modeset triggered by the same HPD event.

In both cases, intel_dp_reset_link_params() does NOT clear
force_train_failure, leaving the debugfs counter stale at a non-zero value.
The test then times out polling for it to reach zero.

Previously this caused an assertion failure, aborting the entire test.
Instead, clear the stale counter by writing 0 to the debugfs and continue.
The test's subsequent assertions (wait_for_hotplug_and_check_bad, link param
verification) will still catch if the fallback genuinely did not occur.

Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
---
 tests/intel/kms_dp_linktrain_fallback.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/tests/intel/kms_dp_linktrain_fallback.c b/tests/intel/kms_dp_linktrain_fallback.c
index 661af7d16..dc9faa216 100644
--- a/tests/intel/kms_dp_linktrain_fallback.c
+++ b/tests/intel/kms_dp_linktrain_fallback.c
@@ -255,8 +255,27 @@ static bool force_failure_and_wait(data_t *data,
 	if (check_condition_with_timeout(data->drm_fd, output,
 					 igt_get_dp_pending_lt_failures,
 					 interval, timeout)) {
-		igt_info("Timed out waiting for pending LT failures\n");
-		return false;
+		/*
+		 * The initial retrain was processed but not all forced LT
+		 * failures were consumed within the timeout. This happens
+		 * when a long HPD fires between the two kernel retrains:
+		 * the long HPD handler sets reset_link_params which resets
+		 * seq_train_failures to 0 during detect, causing the queued
+		 * link_check_work to see needs_link_retrain() == false and
+		 * skip the second retrain. The force_train_failure counter
+		 * is not cleared by intel_dp_reset_link_params(), leaving
+		 * it stale.
+		 *
+		 * This can also occur if the second retrain's modeset fails
+		 * due to lock contention with a concurrent modeset (e.g.
+		 * one triggered by the same HPD event).
+		 *
+		 * Clear the stale counter so it doesn't corrupt subsequent
+		 * iterations of the test loop.
+		 */
+		igt_info("Forced LT failures not fully consumed within timeout "
+			 "— clearing stale counter\n");
+		igt_force_lt_failure(data->drm_fd, output, 0);
 	}
 
 	return true;
-- 
2.25.1