00:56 <steev> many hours later...

00:56 <steev> [ 275.184560] meson_clk_pll_set_rate: sys_pll_dco pll did not lock, trying to restore old rate 4008000000

01:11 <steev> here at least, it looks like it's always sys_pll_dco

06:52 <narmstrong> sys_pll is the cpu dvfs

06:52 <narmstrong> https://github.com/torvalds/linux/blob/105a36f3694edc680f3e9318cdd3c03722e42554/drivers/clk/meson/g12a.c#L1056

06:53 <narmstrong> Weird it only happens when graphic is plugged in

06:53 <narmstrong> The ugly solution is to switch to the performance cpufreq governor so it never changes the cpu frequencies

14:04 <steev> conservative also seems to not cause it to switch as fast

14:43 <Cheaterman> performance sounds like a great workaround in my case

14:43 <Cheaterman> I'll give it a try, thanks to everyone for investigating

15:26 <steev> yeah, i just noticed the one that was "not showing the message" because it was headless, does not have any cpufreq utils installed, and by default, cpufreq-utils sets it to ondemand, at least on debian based systems

15:26 <steev> so it was still set to performance

15:26 <steev> the system i set to conservative still hasn't shown the message

15:27 <steev> https://www.irccloud.com/pastebin/5NjMMUFp/

15:27 <steev> you can ignore the 2GHz, i do that via an overlay

15:28 <steev> i keep going back and forth on whether or not to submit it upstream. not sure what the general consensus is on adding overclocking to the kernel

19:56 <xdarklight> steev: I think so far we don't have any overclocking options upstream. also it would be interesting to see which rate is passed to meson_clk_pll_set_rate() when it fails. possibly it's always the same rate, then we can investigate further

19:59 <xdarklight> steev: if I understand it correctly then we're allowing any M (multiplier) in the range of 128..250 while the vendor driver only allows select M values according to https://github.com/khadas/linux/blob/khadas-vims-5.4.y/drivers/clk/meson/g12a.c#L109-L124

20:00 <steev> that seems limited only if 32bit though?

20:00 <xdarklight> oh, I missed the CONFIG_ARM

20:09 <steev> i can have it spit out rate... assuming i got this right

20:29 <steev> xdarklight: [ 122.288773] meson_clk_pll_set_rate: sys_pll_dco pll did not lock to 3600000000, trying to restore old rate 3408000000 (so far)

20:30 <xdarklight> steev: that should be an M value of 150 (M = 3600000000 / 24MHz * N where N=1, which it typically is)

20:30 <xdarklight> steev: let's see what further testing reports

20:35 <steev> yep, will be waiting

20:51 <steev> https://www.irccloud.com/pastebin/TDZL4vtY/

21:05 <steev> i'm gonna let it run over night, and then collect all of them

21:07 <xdarklight> hmm, Amlogic uses a slightly different waiting loop in their codebase: https://github.com/khadas/linux/blob/khadas-vims-5.4.y/drivers/clk/meson/clk-pll.c#L412-L419

21:09 <xdarklight> and they have this: https://github.com/khadas/linux/blob/khadas-vims-5.4.y/drivers/clk/meson/clk-pll.c#L499-L504

21:14 <xdarklight> ew, that #ifndef is nasty: https://github.com/khadas/linux/commit/b302ad45ae29619d054a835d4cfe51c8200095f4

22:55 <steev> xdarklight: interesting, so, i switched our loop to be same 1000, and 1 udelay - https://paste.debian.net/1254986/ so far, same workload with same cpufreq driver, and nothing just yet

23:05 <steev> oh, and added the 50 udelay too