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
next prev 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