17:43 <Kwiboo> look like scmi clocks are broken for rk3576, linux and tf-a seem to use use different clock indices :-S, e.g. ARMCLK_L in linux = 7 and in tf-a = 10, so linux will request change cpu rate and tf-a change and report rate for gpll instead..., similar for gpu clock 448 vs 456

17:46 <Kwiboo> https://github.com/TrustedFirmware-A/trusted-firmware-a/blob/main/plat/rockchip/rk3576/scmi/rk3576_clk.h <<-- matches vendor kernel indices and not mainline linux indices :/

17:50 <CounterPillow> oops, yeah that needs to be fixed

17:50 <CounterPillow> RK3588 had similar troubles I think

17:54 <Kwiboo> yeah, I was supprised to see <&scmi_clk CLK_GPU> and not a <&scmi_clk SCMI_CLK_GPU> in linux DT for rk3576, was wondering if it was typo, now look like SCMI clock specific indices never was used for rk3576 and instead regular cru clock id is being used

19:56 <diederik> I have a question related to that. Recently https://lore.kernel.org/linux-rockchip/20250307100008.789129-2-amadeus@jmu.edu.cn/ ("arm64: dts: rockchip: enable SCMI clk for RK3528 SoC") was posted (and applied)

19:59 <diederik> The commit description mentions "Same as RK3568 ... ", but in rk356x-base.dtsi only cpu0 has ``clocks = <&scmi_clk 0>``, but none of the other cpu nodes

19:59 <diederik> https://web.git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/tree/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi#n56

20:00 <diederik> Is that an error/omission in rk356x-base.dtsi or is it 'entirely' different?

21:29 <Kwiboo> diederik: all cores will run at the same speed on those socs, at least for runtime it does not seem to matter that much if only one of all cores have clocks and cpu-supply, for proper hw description I think all cores should have a clocks/cpu-supply props, who knows :-)

21:31 <diederik> ok, thanks :)

21:31 <Kwiboo> have been playing around with https://github.com/Kwiboo/linux-rockchip/commits/next-20250307-rk3528/ today and testing the cpu operating points was one of the things, at least with clocks and cpu-supply on all cores linux will only use one scheduling policy

21:38 <CounterPillow> Kwiboo: wrt RK3576 SCMI clocks, I'll look into this tomorrow. sre is busy with EW so I'll probably just be bold and send a patch myself. This would explain why the GPU was so slow for me though lol

21:40 <Kwiboo> CounterPillow: great!, hehe, yeah I can imagine there currently being some unexpected behaviors :-D

21:45 <diederik> Kwiboo: I'll try it to see if it may resolve the resume crashes from https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31265

21:55 <Kwiboo> diederik: just at a first glance I think it is strange that the npu_pvtpll_table is missing e.g. the 100MHz rate that is listed in rk3568_gpu_rates, also look like the code will select 100MHz for gpu and npu when going to suspend, not sure it is related but suspicious

21:56 <Kwiboo> above applies to both gpu/npu

21:57 <diederik> thanks for the hint :)

21:58 <Kwiboo> diederik: also look like at resume it will restore rate that has been set, and npu clock may not have been set at all, so could be worth seeing if the rates is initialized propertly

21:59 <Kwiboo> look like it should not harm if rate = 0 so probably not an issue

22:01 <diederik> One thing Shengfei Xu (xsf) suggested was to add regulator-always-on and -boot-on to the DT. But apart from me not liking that (which is not a real argument), the thing that bothers me is that it does work with rkbin components

22:01 <diederik> So he thinks the problem is with the kernel, but I suspect it's probably (also) with the TF-A patch itself

22:16 <Kwiboo> diederik: could be some issue with gpu and/or npu regulator not being enabled, I added https://github.com/Kwiboo/u-boot-rockchip/commit/658798ebcee175cafa9f2c8ad9f8820a0559dd89 as a workaround for similar issue using npu on vendor kernel with mainline u-boot

22:16 <Kwiboo> we need domain-supply for the power domains as per https://lore.kernel.org/all/20250220-rk3588-gpu-pwr-domain-regulator-v6-0-a4f9c24e5b81@kernel.org/

22:18 <diederik> Ah, the famous "failed to get ack on domain" ;-) I'm still seeing that. But that patch set surely looks interesting :)