11:58 <CounterPillow> Kwiboo: is the sdcard boost thing no longer needed on RK3576 with v2025.07-rc1?

13:07 <CounterPillow> Looks like yes

14:02 <wens> Kwiboo: TIL devfreq has two options that can set this: suspend_freq and resume_freq

15:49 <CounterPillow> Hmmm, RK3576 GPU in linux-next seems broken entirely right now anyway, I'm getting lots of job timeouts. I'll see if the issue isn't there in linux-next/stable and then bisect, I guess, otherwise the problem is with me and potentially my TF-A for all I know

16:05 <CounterPillow> "<CounterPillow> Looks like yes" <-- oops, I should clarify, what I meant there is "yes it's still needed"

16:33 <CounterPillow> Okay the GPU performance doesn't regress in linux-next. Kwiboo: "arm64: dts: rockchip: rk3576: Use scmi gpu clk as main GPU clock" reduces performance in a 1080p run of glmark2-es2-wayland -b terrain from "FPS: 10 FrameTime: 103.639 ms" to "FPS: 3 FrameTime: 369.858 ms"

16:33 <CounterPillow> To be clear, I only picked that patch, the rest of the history seemed unrelated to the rk3576.

16:34 <CounterPillow> In both cases, /sys/class/drm/renderD128/device/devfreq/27800000.gpu/cur_freq shows 950000000

16:38 <CounterPillow> I'm getting stuff like this in the kernel log https://0x0.st/8W6U.txt

17:42 <qschulz> wens: missed the "v2" in the subject for the v2 :)

18:09 <wens> qschulz: yeah, I botched the patman tags

18:10 <wens> anyway, I still have to split out defconfig changes for the two devices you mentioned, though it seems a bit more of a code churn

18:10 <wens> probably still good to make a commit to document the enablement though

18:11 <wens> but I don't have devices to test

18:11 <wens> I think it could either mess up mmc device ordering or boot scripts

18:13 <qschulz> wens: fair enough, you could just not patch them

18:14 <qschulz> or send another series asking their maintainers to look at them and say you've not tested them

18:14 <qschulz> like they are not a requirement for your series, so it's fair game to say you are not comfortable making the patches

20:00 <Kwiboo> CounterPillow: I think the sdcard boost may still be required for sd-card boot on rk3576, I should send a v2 of a mkimage series and rebase my brances ;-)

20:01 <Kwiboo> CounterPillow: thanks for testing the scmi clk patch on rk3576, will try to run some tests on a board, was not expecting such change

20:29 <Kwiboo> CounterPillow: looks like the 950 mhz rate is not handled by tf-a and voltages does not match vendor kernel for gpu opp table for rk3576, so could be that the clk rate is kept at 200mhz even if rate was "changed" to 950mhz opp or similar

20:30 <CounterPillow> Oh, that's a good thought. I did notice the difference in voltages, it looks like we need to read GPU leakage info from OTP to set the voltages right?

20:40 <Kwiboo> my understanding is that for opp where pvtpll is used the real rate used will depend on voltage, pvtpll ring length and silicon quality, and the use of leakage will mostly help with power savings, i.e. bad quality require higher voltage to reach rate and good quality require less voltage

20:40 <CounterPillow> yeah, so I guess we just need to set the voltage to the worst quality level for now?

20:42 <Kwiboo> so with a single voltage value the actual rate will be different depending on quality

20:44 <Kwiboo> yeah, any voltage should work, some boards will run faster than other boards, boogie pointed out that it is possible to read out current rate from pvtpll, based on an average of a number of samples, from CON3 (CAL_CNT) and STATUS1 regs, https://github.com/hbiyik/mmm/commit/9364076644b1ebf3db639f767b79f0a6a1d1f2fc

20:46 <Kwiboo> correction: from PVTPLL_CON1 and PVTPLL_STATUS1 regs

20:46 <CounterPillow> hmmm

20:53 <Kwiboo> with tf-a "set cal cnt = 24, T = 1us" the value in status1 / osc_cnt_avg is possible just the measured avg rate in mhz