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

[sashiko-bot@kernel.org]

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