So, i would like to clarify more about what i have learned about the clock adventures of rk35xx.
In previous post i mentioned that GPU takes PLL frequency from either of CPLL, GPLL, AUPLL, V0PLL, SPLL. This is not complete. For the small cores like i2c, spi, pcie even correct but for bigger cores like CPU, GPU, NPU etc, there is another PLL source called PVTPLL.
PVTPLLs are dedicated to the core, and not shared across diffrent cores, sometimes there are even multiple PVTPLL for single core. (ie: CPU has different PVTPLL for litlle cores and for each big cores).
Unlike normal PLLs, PVTPLLs are meant to be dynamically configured with a twist.
PVTPLLs, gives the best possible frequency output for a given voltage, temperature, and chip quality.
Ie: you request 1Ghz from a PVTPLL, then you set the voltage to your target voltage, and start monitoring the PVTPLL circuit. PVTPLL runs a very small hardware benchmark circuit called ring oscillator and locks the frequency output to maximum possible. It can be 999Mhz, 950Mhz, or 1Ghz. Then the core gets this voltage and uses it.
Now comes the complicated part. This is my understanding someone may be correct me if i am wrong but, PVTPLL is not directly configured by the kernel. Instead it is configured by the BL31.
Kernel uses an interface called SMCCC to communicate with BL31, and request the frequency. BL31 sets the PVTPLL and configures the Core. This whole communication of BL31 with kernel is sometimes referrred as firmware or scmi. There are also other ways to communicate rather than smccc but in our rk3588 it is smccc.
So the initial problem with GPU clocks was not reaching to 1Ghz is that GPU was using normal PLLs rather than PVTPLL with Panthor driver. It seems that even though smi clock of gpu is defined in GPU block of the mainline DTS, it looks the me devfreq is not taking care of it. I think there needs to to be done something about this in mainline. When the issue in mainline is resolved i can also backport this to bsp hopefully.
When it comes to mali blob driver, it is actually using PVTPLL as a source and can sucessfully set the frequency to desired 1Ghz. However there seems to be still a problem. When you request a frequency from BL31 with PVTPLL, it is reporting the requested frequency as set frequency, not what PVTPLL provides., You can see that from the reference TF-A implementation of rk3588.
So how do we know what the actual frequency is?
when i probe the GPU_GRF register with mmm tool, i get directly a kernel crash. I interpret this as a security mechanism somehow since direct access to those registers from kernel or mmapped userspace is not allowed (theory). So my approach now to use pysmccc to probe the BL31, but use functions sip_smc_secure_reg_read and sip_smc_secure_reg_write callbacks to probe GPU_GRF registers. Normally those callbask are meant to access OTP registers, but worth to give it a shot. I also dont know if they are even implemented in BL31 as well.