Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Kunal Joshi <kunal1.joshi@intel.com>
To: igt-dev@lists.freedesktop.org
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Subject: [PATCH i-g-t 04/13] tests/intel/kms_dp_link_training: detect links that failed training
Date: Thu,  1 Oct 2026 13:06:54 +0530	[thread overview]
Message-ID: <20261001073703.5067-5-kunal1.joshi@intel.com> (raw)
In-Reply-To: <20261001073703.5067-1-kunal1.joshi@intel.com>

The current link rate in debugfs is what the driver asked for, not what
the link ended up running at, so a failed link still passes. Nor does
link-status catch it. With both rate and lane count forced, there's
nothing to fall back to, so the driver just disables retraining, and
leaves link-status GOOD.

Check i915_dp_link_retrain_disabled after training. The driver's own
retrain may still be in flight, so keep checking for five seconds
before calling it a pass.

Drop the FIXME. Note that this may start failing links whose max config
never actually trained.

v2:
- Sleep before reading, not after (Sowmiya)
- Rename to assert_link_retrain_not_disabled() (Sowmiya)

Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
---
 tests/intel/kms_dp_link_training.c | 59 +++++++++++++++++++++++++++++-
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/tests/intel/kms_dp_link_training.c b/tests/intel/kms_dp_link_training.c
index 595d78d98..8d079ffb0 100644
--- a/tests/intel/kms_dp_link_training.c
+++ b/tests/intel/kms_dp_link_training.c
@@ -29,6 +29,13 @@
 
 #define RETRAIN_COUNT	1
 
+/*
+ * How long the driver's link recovery is given to reach a verdict, in seconds.
+ * The automatic retrain is queued without a delay, so this only has to cover
+ * one retrain and the fallback selection that follows it.
+ */
+#define LINK_RECOVERY_TIMEOUT	5.0
+
 typedef struct {
 	int drm_fd;
 	uint32_t devid;
@@ -99,9 +106,48 @@ static void assert_link_status_good(data_t *data, bool mst)
 	}
 }
 
+/*
+ * assert_link_retrain_not_disabled - Let the driver's link recovery reach a
+ * verdict and check it did not give up on the link.
+ *
+ * A failed training is not visible the moment the forced retrain flag clears:
+ * the driver clears that flag when the retrain modeset starts and only then
+ * queues its automatic retrain, so the first failure is still in flight. Once
+ * the automatic retrain is used up the driver looks for a configuration to
+ * fall back to, and with both the rate and the lane count forced there is
+ * none. It then marks retraining disabled, which is the one place a link that
+ * failed for good becomes visible.
+ *
+ * Poll for that verdict rather than reading it once, and give recovery the
+ * full timeout to reach it before calling the link trained: sleep before each
+ * read rather than after it, so that the last read is taken once the whole
+ * timeout has elapsed rather than one poll interval short of it.
+ */
+static void assert_link_retrain_not_disabled(data_t *data,
+					     const struct i915_dp_link_config *config)
+{
+	struct timespec start, now;
+	double elapsed;
+
+	clock_gettime(CLOCK_MONOTONIC, &start);
+
+	do {
+		usleep(200 * 1000);
+
+		clock_gettime(CLOCK_MONOTONIC, &now);
+		elapsed = (now.tv_sec - start.tv_sec) +
+			(now.tv_nsec - start.tv_nsec) / 1e9;
+
+		igt_assert_f(!i915_dp_get_link_retrain_disabled(data->drm_fd,
+								data->output),
+			     "Link training at %d lanes, rate %d was given up on.\n",
+			     config->lane_count, config->link_rate);
+	} while (elapsed < LINK_RECOVERY_TIMEOUT);
+}
+
 /*
  * train_link_config - Force one link configuration, re-establish the link and
- * check that the configuration took effect.
+ * check that the configuration took effect and survived training.
  */
 static void train_link_config(data_t *data, bool mst,
 			      const struct i915_dp_link_config *config)
@@ -127,6 +173,16 @@ static void train_link_config(data_t *data, bool mst,
 	igt_info("Current link rate is %d\n", current_link_rate);
 	igt_assert_f(current_link_rate == config->link_rate,
 		     "Link training did not succeed at the forced link rate.\n");
+
+	/*
+	 * The link parameters read back above are the ones the driver asked
+	 * the sink for, not the ones the link ended up running at, so ask the
+	 * driver whether it gave up on the link after training it.
+	 *
+	 * This has to happen before the next force: forcing a rate or a lane
+	 * count resets the recovery state, which would mask the failure.
+	 */
+	assert_link_retrain_not_disabled(data, config);
 }
 
 /*
@@ -222,7 +278,6 @@ static bool run_link_rate_test(data_t *data, bool mst, bool uhbr)
 						   1.0, 20.0), 0);
 	assert_link_status_good(data, mst);
 
-	/* FIXME : Driver may lie max link rate or max lane count */
 	/* Read max_link_rate and max_lane_count */
 	config.link_rate = i915_dp_get_max_link_rate(data->drm_fd, data->output);
 	config.lane_count = i915_dp_get_max_lane_count(data->drm_fd, data->output);
-- 
2.25.1


  parent reply	other threads:[~2026-10-01  7:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01  7:36 [PATCH i-g-t 00/13] Expand kms_dp_link_training coverage Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 01/13] lib/i915/i915_dp: add helpers for the allowed link configs debugfs Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 02/13] tests/intel/kms_dp_link_training: use i915_dp_is_uhbr_rate() Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 03/13] tests/intel/kms_dp_link_training: extract train_link_config() Kunal Joshi
2026-10-01  7:36 ` Kunal Joshi [this message]
2026-10-01  9:05   ` [PATCH i-g-t 04/13] tests/intel/kms_dp_link_training: detect links that failed training S, Sowmiya
2026-10-01  7:36 ` [PATCH i-g-t 05/13] tests/intel/kms_dp_link_training: use the lowest pixel clock mode Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 06/13] tests/intel/kms_dp_link_training: train all allowed link configs Kunal Joshi
2026-10-01  9:05   ` S, Sowmiya
2026-10-01  7:36 ` [PATCH i-g-t 07/13] lib/i915/i915_dp: add i915_dp_get_tc_mode() Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 08/13] tests/intel/kms_dp_link_training: log the DP link inventory Kunal Joshi
2026-10-01  7:36 ` [PATCH i-g-t 09/13] tests/intel/kms_dp_link_training: train each MST topology only once Kunal Joshi
2026-10-01  7:37 ` [PATCH i-g-t 10/13] tests/intel/kms_dp_link_training: add tbt-alt and direct link subtests Kunal Joshi
2026-10-01  7:37 ` [PATCH i-g-t 11/13] lib/igt_dp: add DPCD read helpers Kunal Joshi
2026-10-01  7:37 ` [PATCH i-g-t 12/13] lib/igt_dp: add DPCD link status and channel coding checks Kunal Joshi
2026-10-01  7:37 ` [PATCH i-g-t 13/13] tests/intel/kms_dp_link_training: check the link from the sink side Kunal Joshi
2026-10-01 13:13 ` ✓ i915.CI.BAT: success for Expand kms_dp_link_training coverage (rev2) Patchwork
2026-10-01 16:42 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-01 21:02 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-10-05 16:06   ` Joshi, Kunal1
2026-10-02 17:18 ` ✗ i915.CI.Full: " Patchwork
2026-10-05 16:04   ` Joshi, Kunal1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261001073703.5067-5-kunal1.joshi@intel.com \
    --to=kunal1.joshi@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox