09:16 <qschulz> warpme: I clicked on the link you provided, no 403 and I wasn't logged in with a GitLab account

11:19 <Kwiboo> warpme: yes, I will try to update my combined u-boot branch at github at some point in near future, pushed to u-boot gitlab to ensure the rk3528 changes passed CI

11:26 <warpme> qll. many thx! Btw: some time in past i was trying to get hdmi support on 3528. I recall i got sort of working dw-hdmi (at least in dmesg looked all ok). I was blocked by no vop3 support. Any Yan give me some hints how to reuse 3576 vop2 additions to add minimal vop3 required by 3528. My knowledge is to weak to get reasonable probability i get it working. Have you plans to look on 3528 hdmi or rather we need to wait till Andy

11:26 <warpme> provides minimal vop3 support?

13:02 <Kwiboo> warpme: I have no immediate plan to work on vop support, maybe in future, at the moment my interest is to get improved support in Linux so we can use DTs from dts/upstream in U-Boot ;-)

13:02 <warpme> ah ok. thx for info!

13:07 <Kwiboo> CounterPillow: did you manage to get gpu freq to work on rk3576? if I understand correctly tf-a will mostly configure the gpu to use pvtpll and not a normal pll, instead ft-a set a ring length depending on requested freq and the voltage in opp affect how fast gpu will run

13:08 <CounterPillow> It appears to work with the fixed scmi clk IDs, yes. I no longer get panfrost job timeouts and glmark runs at an acceptable framerate

13:09 <CounterPillow> I didn't look in detail into whether the GPU is at the fastest speed it can be, just that it no longer is stuck at the lowest

13:13 <Kwiboo> cool, looked like the tk3576 use the cru CLK_GPU as core clock so was wondering if it has any affect, maybe because the scmi clock is set to ~200MHz tf-a disable use of pvtpll and the CLK_GPU is one really used

13:13 <CounterPillow> do we not have any OPPs for the GPU or something?

13:15 <CounterPillow> oh, we do.

13:16 <CounterPillow> With no GPU load atm:

13:16 <CounterPillow> root@trixie:~# cat /sys/class/drm/renderD128/device/devfreq/27800000.gpu/cur_freq

13:16 <CounterPillow> 800000000

13:16 <CounterPillow> So doesn't appear to use the highest clock rate, nor does it appear to be idling properly or something

13:17 <Kwiboo> if I understand the ft-a code correctly, the rate must match the rate table, and anythine beside 200MHz will enable use of pvtpll: https://github.com/TrustedFirmware-A/trusted-firmware-a/blob/main/plat/rockchip/rk3576/scmi/rk3576_clk.c#L306-L317

13:18 <Kwiboo> and when pvtpll is enabled the rate or CLK_GPU does not matter

13:18 <CounterPillow> can I check whether pvtpll is enabled from within linux?

13:20 <Kwiboo> I am also not sure that all rates can be achieved with current int plls, i.e. 1188 MHz with div=2 -> 594 MHz

13:22 <Kwiboo> for rk3528 I use the scmi clock as the gpu core clock, and I am wondering if rk3588 and rk3576 should really be using something like that to work as intended, or at least to be able to reach top performance

13:23 <Kwiboo> I do not think the pvtpll regs is in normal device mem and not in secure mem, so should probably be possible to check from Linux

13:23 <CounterPillow> Possibly, I've done zero investigations into performance atm because I'm still at the stage where random things are just straight up broken like eMMC :|

13:27 <Kwiboo> BIT(8) of CRU_CLKSEL_CON(165) seem to determin if pvtpll is used for gpu or normal pll, if I understand the tf-a code correctly

13:28 <Kwiboo> what is the issue with emmc? I played around with https://github.com/Kwiboo/linux-rockchip/commit/62484a44567f472afe5c93504ab771379f04a4a1 to use vendor tap and delay num values, and those are the same values I used in U-Boot

13:56 <CounterPillow> Kwiboo: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/issues/21

13:57 <CounterPillow> tl;dr: if PD_NVM is turned off and then turned back on again, it never comes up the same, and writes to sdhci control registers lock up the SoC

14:36 <Kwiboo> CounterPillow: ahh, thanks for clarification on the emmc issue :)

14:39 <CounterPillow> afaik sre was in the process of asking Rockchip whether that's caused by BIU (linked clocks), but I haven't heard back yet. Linked in the issue is an interesting downstream hack that just forces the PD on in the mmc host driver (a bit sus if you ask me)

14:42 <qschulz> Don't know if related, but IIRC there were issues for the card detect pin when using the card detect function instead of cd-gpios on rk3588 because of some power domain thingy

14:51 <CounterPillow> I know the register range it locks up on when accessing, it's the CQHCI regs within the IP itself.

14:53 <CounterPillow> my best guess (though my guesses are usually terrible) right now is that someone did an oopsie and is auto-gating a clock on PD shutdown but forgot to also auto-ungate it on PD re-power, but its initial power-on-reset state is enabled

14:54 <CounterPillow> if someone is interested in testing that theory, you could probably dump all the clock registers (including the ones in GRF) in u-boot, then disable the PD, then re-enable the PD, then dump them again, and then run the two snippets through diff -u

14:55 <CounterPillow> though if it's a secure clock I think we can't dump that

14:57 <qschulz> secure clock should be dumpable only from OP-TEE/TF-A when in EL3 I believe?

14:57 <qschulz> It wouldn't make sense otherwise

15:00 <CounterPillow> hmmm, maybe I should just use tf-a for this exercise then

15:33 <robmur01> qschulz: the "thingy" being a question of how a powered-off MMC controller can raise its own interrupt to say it needs powering back on ;)

15:33 <qschulz> robmur01: details :)

17:41 <CounterPillow> robmur01: I was wondering why my Reviewed-by/Tested-by e-mail had you lacking from the "To:", apparently however the mailing list delivered it to me made KMail both not have you as a recipient other than the Cc and it messed up the Subject as well :/