From: sashiko-bot@kernel.org
To: "Julien Le Bourg" <julien.lebourg8@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation
Date: Sun, 23 Aug 2026 12:00:39 +0000 [thread overview]
Message-ID: <20260823120039.A7B3B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260823115200.12502-1-julien.lebourg8@gmail.com>
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
next prev parent reply other threads:[~2026-08-23 12:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 9:17 [PATCH] drm/amd/display: Restore self-refresh fallback in DCN21 bandwidth validation Julien Le Bourg
2026-08-23 9:34 ` sashiko-bot
2026-08-23 11:52 ` [PATCH v2] " Julien Le Bourg
2026-08-23 12:00 ` sashiko-bot [this message]
2026-09-09 11:01 ` Julien Le Bourg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260823120039.A7B3B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=julien.lebourg8@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.