Hi, * Florian Boor <florian.boor@xxxxxxxxxxxxxxxxx> [210604 13:31]: > Hi, > > Am 10.05.21 um 13:13 schrieb Florian Boor: > > Am 07.05.21 um 07:47 schrieb Tony Lindgren: > >> Hmm OK, sounds like the voltages might be wrong. > > > > sounds like my guess wasn't that wrong. > > I did some more research and for me it more and more looks like we are missing > the voltage transitions on frequency change completely. > > I added some debug output in omap_vp_forceupdate_scale() and > omap_vc_bypass_scale() and enabled debug output that shows the CPU clock > requency changes. Patch and log are attached. > > The interesting stuff starts in line 123 where the first frequency change happens. > > Maybe I'm missing something and looking in the wrong place, but if voltage > really never gets adapted on some devices then in the best case the device only > wastes power... Yup.. Sounds like the Variscite board boots at some lower opp than what is configured for the kernel in dts. So the immediate fix would be to either limit the max speed, or ensure voltdm_scale() gets called on init. > I wonder if this affects all OMAP4460 or the Variscite one only. This affects all omap4/5 at least as we're missing the cpufreq-dt to voltage domain support like you pointed out. See the last effort to add kernel support for voltage domains at [0] below for more details. I think the way to proceed here would be initially add a regulator usable as cpu-supply for cpufreq-dt that gets the voltdm_scale() as a platform_data pointer and parses the device tree provides opps for supported voltages. Then eventually the legacy platform code for voltage domains can be moved to device drivers. Regards, Tony [0] https://lore.kernel.org/lkml/1392755543-28335-1-git-send-email-nm@xxxxxx/
