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

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

[Julien Le Bourg]

[Why]
Commit b96150a70696 ("drm/amd/display: Should support p-state under
dcn21") made dcn21_validate_bandwidth_fp() call dcn21_fast_validate_bw()
with allow_self_refresh_only = false. This removed the fallback that
re-runs dml_get_voltage_level() with dm_allow_self_refresh when the
first pass finds no voltage level with p-state support.

Some eDP panels advertise high refresh rate modes whose vertical
blanking is too short for a DRAM p-state switch. For example the AUO
1920x1080@360Hz panel of the ASUS ROG Strix G733QSA (Renoir/Cezanne,
DCN 2.1) uses a pixel clock of 800.01 MHz with vtotal 1111, i.e. a
vblank of 31 lines (~77 us). Such modes can only be validated through
the self-refresh fallback. Since the change they fail
dml_get_voltage_level(), dcn21_validate_bandwidth() returns
DC_NOT_SUPPORTED and the mode is pruned:

  [drm] Mode Validation Warning: Unknown Status failed validation.
  create_validate_stream_for_sink: Unhandled validation failure 24
  Rejected mode: "1920x1080": 360 800010 1920 1968 2000 2000 1080 1090 1095 1111 0x48 0xa (ERROR)

leaving the panel with 1920x1080@60 only. This is a user-visible
regression versus v6.18, where the mode was available.

[How]
Pass allow_self_refresh_only = true again in
dcn21_validate_bandwidth_fp(). Modes that support p-state still validate
on the first pass; the fallback is only taken when no p-state capable
voltage level exists, which is exactly the case of these short-vblank
modes.

Note that the issue addressed by commit b96150a70696 ("drm/amd/display:
Should support p-state under dcn21") (atomic_check passing
while commit_tail fails, because sr_exit_time_us differs between
DC_VALIDATE_MODE_ONLY and DC_VALIDATE_MODE_AND_PROGRAMMING) is a
consistency problem between the two validation contexts rather than a
problem with the fallback itself. It should be solved without dropping
modes that have no p-state capable configuration at all.

Tested on ASUS ROG Strix G733QSA (Cezanne, DCN 2.1): 1920x1080@360 is
enumerated again on top of v7.1.8 with this change.

Fixes: b96150a70696 ("drm/amd/display: Should support p-state under dcn21")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5628
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Julien Le Bourg <julien.lebourg8@gmail.com>
---
 drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index e82f2d531211..ceb7ca312577 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -2336,7 +2336,8 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc, struct dc_state *context,
 	/*Unsafe due to current pipe merge and split logic*/
 	ASSERT(context != dc->current_state);
 
-	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from, &vlevel, validate_mode, false);
+	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from,
+				     &vlevel, validate_mode, true);
 
 	if (pipe_cnt == 0)
 		goto validate_out;
-- 
2.55.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Reverting `allow_self_refresh_only` to `true` reintroduces a known `flip_done` timeout regression for MPO configurations because the underlying state consistency issue remains unfixed.
--

--- Patch [1]: [PATCH] drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation ---
commit a448c5ed2983960ea5f4923032f3c31614dd4ecb
Author: Julien Le Bourg <julien.lebourg8@gmail.com>

drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation
    
This commit restores the self-refresh fallback in DCN21 bandwidth validation 
by passing true for allow_self_refresh_only to dcn21_fast_validate_bw(). This 
resolves an issue where high refresh rate modes with short vertical blanking 
were rejected on eDP panels.

> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> index 38c79239004c4..426e9c03fabc6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
> @@ -2347,7 +2347,8 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc, struct dc_state *context,
>  	/*Unsafe due to current pipe merge and split logic*/
>  	ASSERT(context != dc->current_state);
>  
> -	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from, &vlevel, validate_mode, false);
> +	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from,
> +				     &vlevel, validate_mode, true);

[Severity: High]
Does reverting this to true reintroduce the flip_done timeout regression for
MPO configurations?

Since the underlying state consistency issue remains unfixed, it seems
calculate_wm_set_for_vlevel() still overwrites sr_exit_time_us but never
restores it:

drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c: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;
    ...
}

This state leak into dc->current_state causes the next atomic_check to copy
the corrupted state, leading to a flip_done timeout when bandwidth validation
fails during atomic_commit_tail.

>  
>  	if (pipe_cnt == 0)
>  		goto validate_out;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260822091715.6692-1-julien.lebourg8@gmail.com?part=1

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

[Julien Le Bourg]

[Why]
Commit b96150a70696 ("drm/amd/display: Should support p-state under
dcn21") calls dcn21_fast_validate_bw() with allow_self_refresh_only
false. The second dml_get_voltage_level() pass, which retries with
dm_allow_self_refresh when no p-state capable voltage level exists,
is therefore never taken.

That fallback is the only way some short-vblank eDP timings can
validate. The AUO 1920x1080@360 panel on the ASUS ROG Strix G733QSA
(Cezanne, DCN 2.1) runs at 800.01 MHz with vtotal 1111: 31 lines of
vblank, about 77 us, too short for a DRAM p-state. It now fails
dml_get_voltage_level(), dcn21_validate_bandwidth() returns
DC_NOT_SUPPORTED, and the driver keeps 1920x1080@60 only:

  [drm] Mode Validation Warning: Unknown Status failed validation.
  create_validate_stream_for_sink: Unhandled validation failure 24
  Rejected mode: "1920x1080": 360 800010 ... 1095 1111 (ERROR)

This is a regression versus v6.18, where 360 Hz was enumerated and
usable.

That commit dropped the fallback to work around a flip_done timeout
under MPO. atomic_check (DC_VALIDATE_MODE_ONLY) and commit_tail
(DC_VALIDATE_MODE_AND_PROGRAMMING) were observing different
soc.sr_exit_time_us / soc.sr_enter_plus_exit_time_us, so a configuration
could pass check and fail in commit_tail. Passing true again without
fixing that mismatch would bring the timeout back.

[How]
calculate_wm_set_for_vlevel() overlays three DML soc latencies with
each watermark range entry:

	dml->soc.dram_clock_change_latency_us = table_entry->pstate_latency_us;
	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;

and restores only dram_clock_change_latency_us. The stutter latencies
keep the last entry (WM set A) in context->bw_ctx.dml. Watermarks run
only for DC_VALIDATE_MODE_AND_PROGRAMMING, so the leak is written into
dc->current_state at commit_tail. atomic_check validates
dm_state->context with MODE_ONLY and never computes watermarks, so the
two copies of soc can disagree on the next full update, which copies
current_state and re-validates.

Snapshot both stutter latencies in dcn21_validate_bandwidth_fp() and
restore them after dcn21_calculate_wm() and
dcn20_calculate_dlg_params(). The DCN21 DLG path
(dml21_rq_dlg_get_dlg_reg()) still reads soc.sr_enter_plus_exit_time_us
while computing Lwait, so restoring afterwards keeps DLG reading the
same latencies as today; only the leak into dc->current_state goes
away.

With check and commit_tail now using the bounding-box latencies, pass
allow_self_refresh_only true again. Modes that can p-state still
succeed on the first pass; the fallback is taken only when no p-state
capable voltage level exists.

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

Tested on ASUS ROG Strix G733QSA (Cezanne, DCN 2.1): 1920x1080@360 is
enumerated and in daily use on a kernel built with this change. The
original MPO flip_done timeout is not reproduced here; that path is
reasoned from the code.

Fixes: b96150a70696 ("drm/amd/display: Should support p-state under dcn21")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5628
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Julien Le Bourg <julien.lebourg8@gmail.com>
---
v2:
 - Fix the soc stutter-latency leak that b96150a70696 worked around,
   then restore the fallback. v1 only flipped the flag and would have
   reintroduced the MPO flip_done timeout. Reported by the Sashiko
   review bot on v1.

v1: https://lore.kernel.org/amd-gfx/20260822091715.6692-1-julien.lebourg8@gmail.com/

 .../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c  | 25 ++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index e82f2d531211..3697a3139552 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -2321,6 +2321,8 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc, struct dc_state *context,
 				 enum dc_validate_mode validate_mode, display_e2e_pipe_params_st *pipes)
 {
 	bool out = false;
+	double sr_exit_time_us;
+	double sr_enter_plus_exit_time_us;
 
 	BW_VAL_TRACE_SETUP();
 
@@ -2336,7 +2338,8 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc, struct dc_state *context,
 	/*Unsafe due to current pipe merge and split logic*/
 	ASSERT(context != dc->current_state);
 
-	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from, &vlevel, validate_mode, false);
+	out = dcn21_fast_validate_bw(dc, context, pipes, &pipe_cnt, pipe_split_from,
+				     &vlevel, validate_mode, true);
 
 	if (pipe_cnt == 0)
 		goto validate_out;
@@ -2351,9 +2354,29 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc, struct dc_state *context,
 		goto validate_out;
 	}
 
+	/*
+	 * calculate_wm_set_for_vlevel() overrides the DML soc stutter
+	 * latencies with the values of each watermark range entry, but only
+	 * restores dram_clock_change_latency_us. Snapshot the two stutter
+	 * latencies and put them back once the watermark and DLG parameters
+	 * have been computed, so the override cannot leak into
+	 * dc->current_state. A later atomic_check() duplicates that state,
+	 * and validating against mutated latencies is what makes
+	 * atomic_check() and atomic_commit_tail() disagree.
+	 *
+	 * Restoring after dcn20_calculate_dlg_params() keeps the DLG
+	 * computation reading the same latencies as before, so this only
+	 * removes the leak.
+	 */
+	sr_exit_time_us = context->bw_ctx.dml.soc.sr_exit_time_us;
+	sr_enter_plus_exit_time_us = context->bw_ctx.dml.soc.sr_enter_plus_exit_time_us;
+
 	dcn21_calculate_wm(dc, context, pipes, &pipe_cnt, pipe_split_from, vlevel, validate_mode);
 	dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
 
+	context->bw_ctx.dml.soc.sr_exit_time_us = sr_exit_time_us;
+	context->bw_ctx.dml.soc.sr_enter_plus_exit_time_us = sr_enter_plus_exit_time_us;
+
 	BW_VAL_TRACE_END_WATERMARKS();
 
 	goto validate_out;
-- 
2.55.0

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

[sashiko-bot]

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 <julien.lebourg8@gmail.com>

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/20260823115200.12502-1-julien.lebourg8@gmail.com?part=1