On Fri, Oct 02, 2026 at 10:06:56PM +0900, Joonhoe Kim wrote:
> _dpu_core_perf_calc_bw() is called with the new CRTC state but sums
> plane_fetch_bw over drm_atomic_crtc_for_each_plane(), i.e. the planes
> of the committed state. When the CRTC is re-enabled (DPMS on, system
> resume) the committed state has no planes attached, so the check
> computes bw_ctl = 0 and the display runs without an average bandwidth
> vote on the MDP path until some later commit changes a plane -- which
> may not happen for a long time on a static screen such as a lock
> screen.
>
> Seen on a Lenovo TB323FU (SM8850) through the interconnect and DPU
> tracepoints: after DPMS off/on or s2idle, dpu_perf_crtc_update reported
> bw_ctl=0 and qnm_mdp was left at avg_bw=0 (peak 800000) instead of the
> 3728793 kBps voted before, until the next mode change.
>
> Iterate the plane states of the CRTC state being checked instead.
> drm_atomic_crtc_state_for_each_plane_state() falls back to the current
> plane state for planes that are not part of the commit, so the result
> is unchanged for commits that do touch the planes.
>
> With this, bw_ctl is 3728793600 right after DPMS on and after resume.
> Only tested on this device.
>
> Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for
> display")
> Assisted-by: LLM
> Signed-off-by: Joonhoe Kim <[email protected]>
> ---
> Changes in v2:
> - Drop the code comment that repeated the commit message. [Dmitry]
> - Link to v1:
> https://lore.kernel.org/all/[email protected]/
>
> _dpu_core_perf_calc_clk() walks the planes the same way; it is not
> touched here since I have not seen a wrong clock vote from it.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <[email protected]>
--
With best wishes
Dmitry
