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
