13:03 <gamiee> apritzel: hello, I did thunk code for writing to the SID, although, I have no idea about how the CLI arg for writing should look like. Any ideas? Thanks

13:06 <gamiee> For my current usage, I just write 32 bit value, so for me, it will be sufficient to have `sunxi-fel sid-write <offset> <length> <data in 0x...>`, but this might not be suitable for longer data.

13:07 <gamiee> although, it can follow any other write api in sunxi-fel, thus: `sid-write offset file` and `sid-writel offset value`.

13:12 <gamiee> one more thing, isn't there any secret mechanism for locking specific segments on SID? Because, for example, it is not possible to burn anything into NV1, but NV2 area is working just fine. And in other SoCs, I saw this "locking" feature, so maybe it is there too...

15:34 <fraolt> In mainline the A64's OPP table makes the GPU run at 120, 312, or 432 MHz. But the min freq for PLL_GPU is 144 MHz (BSP) or 192 MHz (manual).

15:35 <fraolt> So, I thought that setting PLL_GPU min freq could get rid of the annoying bug above with flipping frames on the pinephone (see my message from earlier).

15:36 <fraolt> If I do so, as expected PLL_GPU runs at 240 MHz when the GPU wants to runs at 120 MHz. :)

15:36 <fraolt> But the flipping frame bug above occurs within minutes instead of hours or days. :(

15:36 <fraolt> Very curious.

15:37 <fraolt> OTOH, when I set the OPP table to 192, 312, or 432 MHz the bug is gone.

15:38 <fraolt> I'm stumped.

20:09 <mps> is there known bug/issue with analogix-anx6345 driver in kernels 6.6.x and 6.7.x

20:10 <mps> I tried to upgrade my olimex teres-i notebook from kernel 6.5.x series to newer and I noticed in dmesg bug which I think is related to anx6345

20:11 <mps> dmesg output is here https://tpaste.us/vNkk

20:18 <diego71> mps: yes I have the same problem

20:18 <diego71> but no clue

20:19 <diego71> And 6.4 does'nt boot at all

20:19 <mps> diego71: for me 6.5.12 works fine

20:19 <mps> and 6.3.x, didn't tried 6.4.x

20:31 <diego71> I'll try 6.5.12

20:37 <mps> not sure but maybe git commit a36f4334b1456cacd5208b7a3677877bccabc43a to mainline kernel could be issue

20:37 <mps> subject line: drm/bridge/analogix/anx6345: Convert to i2c's .probe_new()

20:44 <mps> no, it is not, wrong conclusion

21:21 <apritzel> fraolt: do you have any idea of why the GPU would need a *certain* frequency? The manual speaks of a fractional mode, and the default is 297 MHz, which sounds rather odd

21:22 <apritzel> I would naively assume the GPU just need to be fast enough or as fast as possible, but without the need for certain "magic" frequencies?

21:35 <fraolt> apritzel: I can only refer to the commit that introduced the opp: https://github.com/torvalds/linux/commit/e954a7afe8f5d2587a98b405a71a31ccc0f49e6c

21:37 <fraolt> So, 432 MHz makes sense for best performance and the other two for power saving. It seems that jernej chose 120 MHz because that's what's used in other SoC's as well.

22:57 <apritzel> so if changing 120 to 192 fixes both your problem, and matches the manual's recommendation, that's a clear winner, and probably an easy upstream sell

22:57 <apritzel> but it would still be good to understand why 240 doesn't work

22:59 <apritzel> hence my question about the GPU's sensitivity about certain frequencies.

23:00 <apritzel> IIUC the GPU renders independently from the screen update. It should certainly be fast enough to render before the frame is due, but it doesn't need to be aligned to the video frequency as such?