On 10/28/25 20:52, Dmitry Baryshkov wrote:
On Tue, Oct 28, 2025 at 09:42:57AM +0100, [email protected] wrote:
On 5/7/25 03:38, Jessica Zhang wrote:
Filter out modes that have a clock rate greater than the max core clock
rate when adjusted for the perf clock factor
This is especially important for chipsets such as QCS615 that have lower
limits for the MDP max core clock.
Since the core CRTC clock is at least the mode clock (adjusted for the
perf clock factor) [1], the modes supported by the driver should be less
than the max core clock rate.
[1]
https://elixir.bootlin.com/linux/v6.12.4/source/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c#L83
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Jessica Zhang <[email protected]>
---
Changes in v2:
- *crtc_clock -> *mode_clock (Dmitry)
- Changed adjusted_mode_clk check to use multiplication (Dmitry)
- Switch from quic_* email to OSS email
- Link to v1:
https://lore.kernel.org/lkml/[email protected]/
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 35
++++++++++++++++++---------
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 3 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 +++++++++
3 files changed, 39 insertions(+), 11 deletions(-)
This test doesn't take in account if the mode is for a bonded DSI mode, which
is the same mode on 2 interfaces doubled, but it's valid since we could
literally
set both modes separately. In bonded DSI this mode_clk must be again divided bv
2
in addition to the fix:
https://lore.kernel.org/linux-arm-msm/[email protected]/
From the docs:
* Since this function is both called from the check phase of an atomic
* commit, and the mode validation in the probe paths it is not allowed
* to look at anything else but the passed-in mode, and validate it
* against configuration-invariant hardware constraints. Any further
* limits which depend upon the configuration can only be checked in
* @mode_fixup or @atomic_check.
Additionally, I don't think it is correct to divide mode_clk by two. In
the end, the DPU processes the mode in a single pass, so the perf
constrains applies as is, without additional dividers.
Sorry but this is not correct, the current check means nothing. If you
enable 2 separate DSI outputs or enable then in bonded mode, the DPU
processes it the same so the bonded doubled mode should be valid.
The difference between separate or bonded DSI DPU-wise is only the
synchronisation of vsyncs between interfaces.
So this check against the max frequency means nothing and should be
removed, but we should solely rely on the bandwidth calculation instead.
Neil
I'm trying to find a correct way to handle that, I have tried that:
===========================><========================================
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48c3aef1cfc2..6aa5db1996e3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
