All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.