[PATCH 0/3] drm/amd/display: HDMI FRL training fixes for slow sinks

[PATCH 0/3] drm/amd/display: HDMI FRL training fixes for slow sinks

[Andrzej Piątyszek]

With FRL on by default since commit 5fd3b60d9b80 ("drm/amd/display:
Enable HDMI FRL by default"), an RX 9070 XT mostly trains a Samsung
QE65Q80T (2020) at 6 Gbps x 3, where 4K 120 Hz needs DSC. Windows on
the same machine trains it at 10 Gbps x 4.

The TV needs one TxFFE step at 10 Gbps x 4, but requested levels never
reach the PHY; with patch 1, the driver programs them right away. The
TV sometimes answers an LTP request only after up to 967 ms, while the
driver waits only 220 ms in LTS:3; patch 2 raises the limit to 1 s.
After waking up, the TV can stay silent at 10 Gbps x 4 for up to about
four seconds, but link verification gives up on that rate after one
attempt; with patch 3, verification tries the same rate again first, as
the enable path does.

Tested on 7.3 with an equivalent backport. Without the series, 4 of 6
boots and TV wake-ups ended at 6 Gbps x 3. With patches 1 and 2, 16 of
20 reached 10 Gbps x 4, and the other 4 are the case patch 3 handles.
With all three, all 63 boots and TV wake-ups over 12 days reached
10 Gbps x 4. In 13 of them the sink stayed silent at first during link
verification and answered after one to three more attempts at the same
rate. On amd-staging-drm-next the series is build-tested only.

Andrzej Piątyszek (3):
  drm/amd/display: Apply requested TxFFE level right away in FRL
    training
  drm/amd/display: Wait up to 1 s for slow sinks in FRL link training
  drm/amd/display: Retry the same FRL rate after a sink timeout

 .../display/dc/link/protocols/link_hdmi_frl.c | 56 +++++++++++--------
 1 file changed, 33 insertions(+), 23 deletions(-)


base-commit: 47df73aa49d1988c8f684b7caf8be6570e966844
-- 
2.56.0

[PATCH 1/3] drm/amd/display: Apply requested TxFFE level right away in FRL training

[Andrzej Piątyszek]

When the sink answers an LTP request with 0xE (next TxFFE level) in
LTS:3, hdmi_frl_perform_link_training() programs the new level only on
the next poll, and only if the sink has set FLT_update again by then.
The sink usually has not, as the driver has just cleared FLT_update.
The sink keeps asking, and current_FFE advances without reaching the
PHY.

A Samsung QE65Q80T (2020) needs one TxFFE step at 10 Gbps x 4, so its
link mostly ends up at 6 Gbps x 3.

Program the requested level right away and drop the deferred
programming.

Fixes: cbb8e2044b9e ("drm/amd/display: Add DC link support for FRL")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Andrzej Piątyszek <andrzej.piatyszek@gmail.com>
---
 .../display/dc/link/protocols/link_hdmi_frl.c | 33 ++++++++-----------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
index 960f18fe2..78e62bfec 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
@@ -640,26 +640,6 @@ static enum link_result hdmi_frl_perform_link_training(struct ddc_service *ddc_s
 				prev_flt_update = scdc_update.fields.FLT_UPDATE;
 			}
 
-			/*Set TxFFE = TxFFE0*/
-			/*Program FFE_Levels - scdc_config has this field at 0 */
-			if (override_FFE) {
-				if (current_FFE == 0)
-					dio_link_enc->funcs->prog_eq_setting(dio_link_enc, current_FFE,
-							test_req.fields.TXFFE_DEEMPHASIS,
-							test_req.fields.TXFFE_PRESHOOT,
-							test_req.fields.TXFFE_NOFFE,
-							link_settings);
-				else {
-					if (scdc_update.fields.FLT_UPDATE)
-						dio_link_enc->funcs->prog_eq_setting(dio_link_enc, current_FFE,
-								test_req.fields.TXFFE_DEEMPHASIS,
-								test_req.fields.TXFFE_PRESHOOT,
-								test_req.fields.TXFFE_NOFFE,
-								link_settings);
-				}
-				FRL_INFO("FRL LINK TRAINING:  TxFFE = %d.\n", current_FFE);
-				override_FFE = false;
-			}
 			if (scdc_update.fields.FLT_UPDATE) {
 				offset = HDMI_SCDC_LTP_REQ;
 				link_query_ddc_data(ddc_service, slave_address,
@@ -749,6 +729,19 @@ static enum link_result hdmi_frl_perform_link_training(struct ddc_service *ddc_s
 					ln1_pattern = pre_ln1_pattern;
 					ln2_pattern = pre_ln2_pattern;
 					ln3_pattern = pre_ln3_pattern;
+
+					/*
+					 * The sink re-evaluates the link as soon as FLT_update
+					 * is cleared, so program the requested level now.
+					 */
+					dio_link_enc->funcs->prog_eq_setting(dio_link_enc,
+							current_FFE,
+							test_req.fields.TXFFE_DEEMPHASIS,
+							test_req.fields.TXFFE_PRESHOOT,
+							test_req.fields.TXFFE_NOFFE,
+							link_settings);
+					FRL_INFO("FRL LINK TRAINING:  TxFFE = %d.\n", current_FFE);
+					override_FFE = false;
 				}
 
 				FRL_INFO("FRL LINK TRAINING:  Setting Training Pattern [ln0,ln1,ln2,ln3] = [%d,%d,%d,%d].\n",
-- 
2.56.0

[PATCH 2/3] drm/amd/display: Wait up to 1 s for slow sinks in FRL link training

[Andrzej Piątyszek]

LTS:3 gives the sink 220 ms (320 ms at 16 Gbps and above) to answer an
LTP request before the driver gives up on the rate. A Samsung QE65Q80T
(2020) sometimes answers at 10 Gbps x 4 only after 225 to 967 ms, so
link verification falls back to 6 Gbps x 3.

Wait up to 1 s at every rate. Sinks that answer within the old limit
are unaffected; a sink that never answers costs up to 1 s per rate in
the polling loop instead of 220 ms.

Fixes: cbb8e2044b9e ("drm/amd/display: Add DC link support for FRL")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Andrzej Piątyszek <andrzej.piatyszek@gmail.com>
---
 .../drm/amd/display/dc/link/protocols/link_hdmi_frl.c    | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
index 78e62bfec..97b2b9b74 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
@@ -612,10 +612,13 @@ static enum link_result hdmi_frl_perform_link_training(struct ddc_service *ddc_s
 
 		FRL_INFO("FRL LINK TRAINING:  Poll for FLT_UPDATE.\n");
 		/*LTS:3: Start Link Training*/
-		/*Start FLT Timer = 200 ms, or 300ms if link rate >= 16Gbps*/
+		/*
+		 * Start FLT Timer. Some sinks need longer than the nominal 200 ms
+		 * (300 ms at 16 Gbps and above) to answer an LTP request, so wait
+		 * up to 1 s before giving up on this rate.
+		 */
 		num_polls = 0;
-		if (link_settings->frl_link_rate >= HDMI_FRL_LINK_RATE_16GBPS)
-			poll_timeout_ns = 320 * 1000 * 1000;
+		poll_timeout_ns = 1000 * 1000 * 1000;
 
 		flt_poll_start = dm_get_timestamp(ddc_service->ctx);
 		uint8_t prev_flt_update = 0;
-- 
2.56.0

[PATCH 3/3] drm/amd/display: Retry the same FRL rate after a sink timeout

[Andrzej Piątyszek]

hdmi_frl_perform_link_training_with_fallback() lowers the rate after any
failed attempt, even when the sink never answered. The enable path,
hdmi_frl_perform_link_training_with_retries(), tries the same rate again
instead.

After waking up, a Samsung QE65Q80T (2020) can stay silent at
10 Gbps x 4 for a few seconds and then train in about 33 ms. Link
verification moves to a lower rate before that happens.

After a timeout, try the same rate again, up to max_retries times per
verification, as the enable path does. A sink that never answers costs
up to three extra attempts.

Fixes: cbb8e2044b9e ("drm/amd/display: Add DC link support for FRL")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Andrzej Piątyszek <andrzej.piatyszek@gmail.com>
---
 .../amd/display/dc/link/protocols/link_hdmi_frl.c  | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
index 97b2b9b74..129834d6d 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
@@ -818,9 +818,14 @@ enum link_result hdmi_frl_perform_link_training_with_fallback(
 	enum clock_source_id frl_phy_clock_source_id)
 {
 	enum link_result status = LINK_RESULT_UNKNOWN;
+	unsigned int retries = 0;
+	unsigned int max_retries = 3;
 
 	DC_LOGGER_INIT(link->ctx->logger);
 
+	if (link->preferred_hdmi_frl_settings.valid)
+		max_retries = link->preferred_hdmi_frl_settings.max_retries;
+
 	/* FRL Link Training */
 	while (status != LINK_RESULT_FALLBACK) {
 		if (link->frl_link_settings.frl_link_rate ==
@@ -846,6 +851,15 @@ enum link_result hdmi_frl_perform_link_training_with_fallback(
 		if (status == LINK_RESULT_SUCCESS)
 			break;
 
+		/*
+		 * A sink that is still waking up may not answer at all. Retry the
+		 * same rate before going lower, as many times as link enable does.
+		 */
+		if (status == LINK_RESULT_TIMEOUT && retries < max_retries) {
+			retries++;
+			continue;
+		}
+
 		link->frl_link_settings.frl_link_rate--;
 		if (link->frl_link_settings.frl_link_rate <
 				HDMI_FRL_LINK_RATE_6GBPS_4LANE)
-- 
2.56.0

Re: [PATCH 1/3] drm/amd/display: Apply requested TxFFE level right away in FRL training

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] drm/amd/display: busy loop CPU stall in
  hdmi_frl_perform_link_training() [1]
--

commit 91fe51195d67c76e4e3cbba1f95c962c1ab46a75
Author: Andrzej Piątyszek <andrzej.piatyszek@gmail.com>

drm/amd/display: Apply requested TxFFE level right away in FRL training

This commit programs the requested TxFFE level immediately during HDMI FRL
link training when the sink requests the next FFE level, rather than
deferring it to the next poll iteration.

> diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> index 960f18fe275b2..78e62bfec49c7 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> @@ -640,26 +640,6 @@ static enum link_result hdmi_frl_perform_link_training(struct ddc_service *ddc_s
>  				prev_flt_update = scdc_update.fields.FLT_UPDATE;
>  			}
>  
> -			/*Set TxFFE = TxFFE0*/
> -			/*Program FFE_Levels - scdc_config has this field at 0 */
> -			if (override_FFE) {
> -				if (current_FFE == 0)
> -					dio_link_enc->funcs->prog_eq_setting(dio_link_enc, current_FFE,
> -							test_req.fields.TXFFE_DEEMPHASIS,
> -							test_req.fields.TXFFE_PRESHOOT,
> -							test_req.fields.TXFFE_NOFFE,
> -							link_settings);
> -				else {
> -					if (scdc_update.fields.FLT_UPDATE)
> -						dio_link_enc->funcs->prog_eq_setting(dio_link_enc, current_FFE,
> -								test_req.fields.TXFFE_DEEMPHASIS,
> -								test_req.fields.TXFFE_PRESHOOT,
> -								test_req.fields.TXFFE_NOFFE,
> -								link_settings);
> -				}
> -				FRL_INFO("FRL LINK TRAINING:  TxFFE = %d.\n", current_FFE);
> -				override_FFE = false;
> -			}
>  			if (scdc_update.fields.FLT_UPDATE) {

[Severity: Medium]
This problem wasn't introduced by this patch, but can the SCDC status
polling loops in hdmi_frl_perform_link_training() [1] stall the CPU
core by busy-spinning between polls?

drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c:hdmi_frl_perform_link_training() {
    ...
		do {
			flt_poll_curr = dm_get_timestamp(ddc_service->ctx);
					elapsed = dm_get_elapse_time_in_ns(ddc_service->ctx,
						flt_poll_curr, flt_poll_start);
			if (elapsed < (num_polls * wait_time_ns))
				continue;
			num_polls++;
    ...
}

When FRL link training runs on an HDMI 2.1 display, both the FLT_READY and
FLT_UPDATE loops spin on dm_get_timestamp() and dm_get_elapse_time_in_ns()
while waiting for each 2 ms wait_time_ns interval without sleeping or
yielding the CPU, which monopolizes the core for up to 1 second and can
trigger soft lockup warnings.

[1] https://sashiko.dev/#/bug/linux-4798172c-1032-4f55-aa52-1cbebc19449f

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110130956.160024-1-andrzej.piatyszek@gmail.com?part=1

Re: [PATCH 2/3] drm/amd/display: Wait up to 1 s for slow sinks in FRL link training

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/amd/display: unconditional 1s LTS:3 timeout violates HDMI
  T_FLT spec
--

commit 2cb267c6df8cc9565556b092b803e0c5c55db242
Author: Andrzej Piątyszek <andrzej.piatyszek@gmail.com>

drm/amd/display: Wait up to 1 s for slow sinks in FRL link training

This commit increases the FRL link training state 3 (LTS:3) polling timeout
in hdmi_frl_perform_link_training() to 1 second across all link rates to
accommodate slow HDMI sinks.

> diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> index 78e62bfec49c7..97b2b9b74cc71 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_hdmi_frl.c
> @@ -612,10 +612,13 @@ static enum link_result hdmi_frl_perform_link_training(struct ddc_service *ddc_s
>  
>  		FRL_INFO("FRL LINK TRAINING:  Poll for FLT_UPDATE.\n");
>  		/*LTS:3: Start Link Training*/
> -		/*Start FLT Timer = 200 ms, or 300ms if link rate >= 16Gbps*/
> +		/*
> +		 * Start FLT Timer. Some sinks need longer than the nominal 200 ms
> +		 * (300 ms at 16 Gbps and above) to answer an LTP request, so wait
> +		 * up to 1 s before giving up on this rate.
> +		 */
>  		num_polls = 0;
> -		if (link_settings->frl_link_rate >= HDMI_FRL_LINK_RATE_16GBPS)
> -			poll_timeout_ns = 320 * 1000 * 1000;
> +		poll_timeout_ns = 1000 * 1000 * 1000;

[Severity: Medium]
Does setting poll_timeout_ns to 1 second unconditionally for all sinks break
HDMI 2.1/2.2 link layer compliance testing when test_req.fields.FLT_NO_TIMEOUT
is 0?

The HDMI specification limits the LTS:3 T_FLT timer to 200 ms nominal (220 ms
max) for rates below 16 Gbps and 300 ms nominal (320 ms max) for 16 Gbps and
above.  Commits f38686268b0d ("drm/amd/display: Fix HDMI2.2 LT timeout
duration"), 536ad3cf1871 ("drm/amd/display: Fix HDMI FRL FFE compliance test")
and 007834be6760 ("drm/amd/display: Adjust HDMI FRL LT timeout") specifically
tuned poll_timeout_ns to 220 ms and 320 ms so the elapsed time in LTS:3 does
not exceed the spec-defined limits during compliance tests.  Could the 1 second
timeout be applied only to affected displays via an EDID quirk instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110130956.160024-1-andrzej.piatyszek@gmail.com?part=2

Re: [PATCH 0/3] drm/amd/display: HDMI FRL training fixes for slow sinks

[Andrzej Piątyszek]

Please drop this series.

As Sashiko pointed out, patch 2 raises the LTS:3 timeout past the HDMI
T_FLT limit, which commits f38686268b0d and 007834be6760 tuned for
compliance. I'll send a v2 that keeps patch 1 as a general fix and
enables the rest only for the affected TV, through an EDID quirk.

Thanks,
Andrzej


wt., 10 lis 2026 o 14:15 Andrzej Piątyszek
<andrzej.piatyszek@gmail.com> napisał(a):
>
> With FRL on by default since commit 5fd3b60d9b80 ("drm/amd/display:
> Enable HDMI FRL by default"), an RX 9070 XT mostly trains a Samsung
> QE65Q80T (2020) at 6 Gbps x 3, where 4K 120 Hz needs DSC. Windows on
> the same machine trains it at 10 Gbps x 4.
>
> The TV needs one TxFFE step at 10 Gbps x 4, but requested levels never
> reach the PHY; with patch 1, the driver programs them right away. The
> TV sometimes answers an LTP request only after up to 967 ms, while the
> driver waits only 220 ms in LTS:3; patch 2 raises the limit to 1 s.
> After waking up, the TV can stay silent at 10 Gbps x 4 for up to about
> four seconds, but link verification gives up on that rate after one
> attempt; with patch 3, verification tries the same rate again first, as
> the enable path does.
>
> Tested on 7.3 with an equivalent backport. Without the series, 4 of 6
> boots and TV wake-ups ended at 6 Gbps x 3. With patches 1 and 2, 16 of
> 20 reached 10 Gbps x 4, and the other 4 are the case patch 3 handles.
> With all three, all 63 boots and TV wake-ups over 12 days reached
> 10 Gbps x 4. In 13 of them the sink stayed silent at first during link
> verification and answered after one to three more attempts at the same
> rate. On amd-staging-drm-next the series is build-tested only.
>
> Andrzej Piątyszek (3):
>   drm/amd/display: Apply requested TxFFE level right away in FRL
>     training
>   drm/amd/display: Wait up to 1 s for slow sinks in FRL link training
>   drm/amd/display: Retry the same FRL rate after a sink timeout
>
>  .../display/dc/link/protocols/link_hdmi_frl.c | 56 +++++++++++--------
>  1 file changed, 33 insertions(+), 23 deletions(-)
>
>
> base-commit: 47df73aa49d1988c8f684b7caf8be6570e966844
> --
> 2.56.0
>