AMD General Your change already being considered in below two changes. Please kindly check below two changes: https://gerrit.core.linux.amd.com/plugins/gitiles/upstream/github.com/torvalds/linux/+/ae5df7bc72d919c669301e https://gerrit.core.linux.amd.com/plugins/gitiles/upstream/github.com/torvalds/linux/+/d6751306a6e0fbb09
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
