Re: [PATCH v2] drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The stutter latency leak fixed for DCN 2.1 is explicitly left unpatched for DCN 3.01, leaving it vulnerable to MPO flip_done timeouts.
--

--- Patch [1]: [PATCH v2] drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation ---
commit 65e2baa225f2dd040a51a1cbfe0d3ae3aa5e8b28
Author: Julien Le Bourg <[email protected]>

drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation

This commit restores the self-refresh fallback in DCN21 bandwidth validation
to allow short-vblank eDP timings to validate. It also addresses a state leak
in the DCN21 watermark calculation by saving and restoring the stutter
latencies.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5628

> dcn301_fpu.c has the same helper and the same restore gap. Left alone;
> I cannot test DCN 3.01.

[Severity: High]
This isn't a bug introduced by this patch, but since the stutter latency
leak is explicitly left unpatched for DCN 3.01, will it remain vulnerable
to MPO flip_done timeouts?

In drivers/gpu/drm/amd/display/dc/dml/dcn301/dcn301_fpu.c, when
dcn301_fpu_calculate_wm_and_dlg() calculates watermarks, it calls
calculate_wm_set_for_vlevel() which mutates the latencies without
restoring them:

calculate_wm_set_for_vlevel()
	...
	dml->soc.sr_exit_time_us = table_entry->sr_exit_time_us;
	dml->soc.sr_enter_plus_exit_time_us = table_entry->sr_enter_plus_exit_time_us;

Does this state mismatch between atomic_check and commit_tail cause flip_done
timeouts under MPO on DCN 3.01 hardware where p-state switching is possible,
potentially leading to display freezes or compositor crashes? Should the
same snapshot and restore fix be applied to dcn301_fpu.c to prevent this
leak into dc->current_state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1