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
