Hi Jerry,
Thanks for the titles. Before dropping my patch I tested both changes on
my hardware:
"drm/amd/display: Fix HDMI2.2 LT timeout duration"
"drm/amd/display: Adjust HDMI FRL LT timeout"
Setup: ASUS ROG Flow Z13 (GZ302EA, Strix Halo, DCN 3.5), LG C2 OLED
(firmware 43.21.74), certified Ultra High Speed HDMI cable, 4K120 10-bit
RGB = FRL 10 Gbps x4. Kernel 7.3 (CachyOS 7.3.0-4). I applied the first
change and the 220 ms line from the second (d6751306 in
amd-staging-drm-next) to link_hdmi_frl.c, and left out the FLT_no_timeout
compliance rework in between, since a TV never sets that bit.
Test: 20 mode switches 4K60 -> 4K120 with drm.debug=0x2, time measured
from "Poll for FLT_UPDATE" to PASSED/FAILED.
220 ms (your changes): 28 trainings, 4 timed out at 221 ms
("Timeout waiting for FLT_UPDATE"). Each one
passed on the driver's retry ~0.4 s later.
~300 ms (my patch): 29 trainings, 0 timeouts. Loop time 196-244 ms,
median 208 ms, 9 of 29 over 220 ms.
Over about 270 earlier trainings with this TV the longest was 257 ms. So
220 ms works, but with this sink it costs a retry on roughly one link-up
in three to seven. Would you consider 300 ms for every rate, the same as
for >= 16G? I'm happy to test any patch.
Separately, a regression I hit in 7.3 that is unrelated to the timeout:
fill_stream_properties_from_drm_display_mode() in amdgpu_dm_connector.c
now does
if (is_hdmi_ep)
adjust_colour_depth_from_display_info(timing_out, info);
which clamps FRL streams to the sink's max_tmds_clock. v7.2 only did this
for SIGNAL_TYPE_HDMI_TYPE_A. On the C2 (600 MHz max TMDS), 4K60 10-bit
needs 742.5 MHz, so it is lowered to 8-bit, update_stream_signal() then
moves the stream to TMDS, and the TV loses HDR at 4K60. On 7.2 the same
mode trained FRL at 6G x4, 10-bit. 4K120 is unaffected only because no
depth fits under 600 MHz, so the clamp gives up.
Locally I changed the condition to
if (is_hdmi_ep && stream->signal != SIGNAL_TYPE_HDMI_FRL)
At that point stream->signal is still the sink's signal, and
update_stream_signal() runs again after the fill. With this, 4K60 is back
to FRL 6G x4, 10-bit, with HDR. dc_validate_stream() still checks the FRL
bandwidth, and the caller falls back to the next depth if it doesn't fit.
I can send this as a proper patch if that helps.
On Fri, Oct 23, 2026 at 11:59 AM Zuo, Jerry <[email protected]> wrote:
> AMD General
>
> > -----Original Message-----
> > From: Zuo, Jerry
> > Sent: Friday, October 23, 2026 11:50
> > To: 'David Janice' <[email protected]>;
> [email protected]
> > Cc: Wentland, Harry <[email protected]>; Li, Sun peng (Leo)
> > <[email protected]>; Rodrigo Siqueira <[email protected]>; Deucher,
> > Alexander <[email protected]>; [email protected]
> > Subject: RE: [PATCH] drm/amd/display: Allow 300 ms for HDMI FRL link
> > training at every rate
> >
> > Your change already being considered in below two changes. Please kindly
> > check below two changes:
> > "drm/amd/display: Fix HDMI2.2 LT timeout duration"
> > "drm/amd/display: Adjust HDMI FRL LT timeout"
>
> Just add commit title for your reference.
>
> Regards,
> Jerry
> >
> > Regards,
> > Jerry
> >
> > > -----Original Message-----
> > > From: David Janice <[email protected]>
> > > Sent: Saturday, September 19, 2026 21:31
> > > To: [email protected]
> > > Cc: Wentland, Harry <[email protected]>; Li, Sun peng (Leo)
> > > <[email protected]>; Rodrigo Siqueira <[email protected]>; Deucher,
> > > Alexander <[email protected]>; Zuo, Jerry
> > <[email protected]>;
> > > [email protected]; David Janice <[email protected]>
> > > Subject: [PATCH] drm/amd/display: Allow 300 ms for HDMI FRL link
> > > training at every rate
> > >
> > > [You don't often get email from [email protected]. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > hdmi_frl_perform_link_training() gives LTS:3 a single budget of 105
> > > polls at 2 ms (~210 ms) that starts at the FRL_Rate write and is not
> > > restarted when the sink raises its first FLT_update with the LTP
> > > request. A sink that needs close to
> > > 200 ms after the LTP request to report lock therefore fails whenever
> > > its LTP request itself takes more than a few tens of ms.
> > >
> > > Measured on an LG C2 (GSM 49352, 2022) driven by a Strix Halo DP-HDMI
> > > FRL PCON, DPMS off/on with drm.debug=0x2, kernel 7.2.6:
> > >
> > > 6G x4 (3840x2160@60 10bpc): LTP request at poll 11 (~21 ms),
> > > lock at poll 100 (~179 ms later): PASSED first try.
> > > 10G x4 (3840x2160@120 10bpc): LTP request at poll 22 (~44 ms),
> > > no lock by poll 105: "FAILED - Timeout waiting for
> FLT_UPDATE".
> > > Retry 200 ms later: LTP request at poll 11, lock at poll 101:
> > > PASSED.
> > >
> > > The sink answers FLT_READY on the first poll every time and locks in a
> > > steady
> > > ~180 ms at both rates, so it is neither slow to wake nor marginal; the
> > > total just does not fit 210 ms once the LTP request is late, which
> > > happens far more often at 10G. On this system that is the difference
> > > between reliable DPMS wakes at
> > > 4K60 and mostly dark ones at
> > > 4K120: hdmi_frl_perform_link_training_with_retries() retrains at the
> > > same rate up to four times 200 ms apart and the output is then left
> dark.
> > >
> > > "drm/amd/display: Update and revert FRL LT Timeout behaviour" already
> > > allows 155 polls (~300 ms) for 16 Gbps and above. Use that budget at
> > > every rate. With the change applied to 7.2.6, five consecutive DPMS
> > > wakes at 10G
> > > x4 trained on the first attempt; three of them locked at poll 104-105,
> i.e.
> > > inside the last 1-2 polls of the old budget.
> > >
> > > Cc: Fangzhi Zuo <[email protected]>
> > > Signed-off-by: David Janice <[email protected]>
> > > ---
> > > .../amd/display/dc/link/protocols/link_hdmi_frl.c | 14
> > > +++++++++++---
> > > 1 file changed, 11 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 7f93009..005feb9 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
> > > @@ -528,10 +528,18 @@ 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 = 300 ms. HDMI 2.1 specifies
> > > + FLT_TIMEOUT = 200
> > > ms,
> > > + * but this budget runs from the FRL_Rate write to the
> final
> > > + * FLT_update and some sinks need more than that in
> total: an LG
> > C2
> > > + * (2022) at 10G x4 raises its first FLT_update (the
> LTP request)
> > > + * ~45 ms after the rate write and reports lock a
> further ~180 ms
> > > + * later, ~225 ms in all, so it failed the 105-poll
> (~210 ms) budget on
> > > + * most DPMS wakes at 4K120 while at 6G x4 (~20 ms +
> > > + ~180 ms) it
> > > just
> > > + * fit. Use the 300 ms already allowed for >= 16 Gbps
> at every rate.
> > > + */
> > > num_polls = 0;
> > > - if (link_settings->frl_link_rate >=
> HDMI_FRL_LINK_RATE_16GBPS)
> > > - max_polls = 155;
> > > + max_polls = 155;
> > >
> > > while (num_polls < max_polls) {
> > > flt_poll_cur_time =
> > > dm_get_timestamp(ddc_service->ctx);
> > > --
> > > 2.55.0
>
>
