On 1/15/26 6:08 PM, Dmitry Baryshkov wrote:
On Mon, Jan 12, 2026 at 04:54:28AM -0300, Val Packett wrote:
On 1/12/26 3:31 AM, Xilin Wu wrote:
On 5/7/2025 9:38 AM, 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]>
---
Hi. This patch effectively filters out the 3840x2160@120Hz mode on
SC8280XP CRD. The calculated adjusted_mode_clk is 623700, which slightly
exceeds the supported max core clock of 600000.
However, 4K 120Hz works flawlessly with the limit removed on this
platform. I even tried connecting two 4K 120Hz displays, and they can
work properly simultaneously. Is it possible to bring back support for
this mode, or adjust the limits?
hm, interestingly on X1E80100 we didn't hit *that* limit,
the adjusted_mode_clk (576318) was only above what disp_cc_mdss_mdp_clk was
Hmm, what is your modeline then? Xilin's mode params looks sane and
standard enough.
as mentioned in
https://gitlab.freedesktop.org/drm/msm/-/issues/38#note_3216051:
"3840x2160": 120 1097750 3840 3888 3920 4000 2160 2166 2176 2287 0x40 0x9
## 1097750 / 2 = 548875; 548875 * 1.05 = 576318.75
vs.
"3840x2160": 120 1188000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
## 1188000 / 2 = 594000; 594000 * 1.05 = 623700
Yeah, what's interesting is that both are just slightly above the max
disp_cc_mdss_mdp_clk_src on the respective platforms. 576318 is only
slightly above 575000, and 623700 is only slightly above 608000. So it's
actually the *same* limit, just that the numbers are different per
platform (sorry for any confusion).
Sooo.. what *is* the deal with the 105% inefficiency factor, is it
possible to find out where it came from and why it's hardcoded to that
number everywhere?
Can we add a loop that reduces it until the result fits into the max
clk? Or should the factor be ignored for this calculation maybe?
~val
