00:03 <apritzel> I see. The H700/T507 (H616 siblings) are the newest chips with *some* kind of support. Panfrost works now (patches in -next by now, I believe).

00:04 <apritzel> bunting: The display output patches are on the list, written for some kind of LCD, though I don't know from the top of my head which interface exactly

00:05 <apritzel> tokyovigilante would know more about that ^^^^

00:06 <bunting> AFAIK the display driving chip I'll use support quite a lot of interface including SPI, 8080, 6800, etc, so I guess any one of it would work.

00:07 <bunting> Thanks for thd

00:07 <bunting> Thanks for the answer!

00:07 <apritzel> but that's then not driven by the display engine, but is an LCD with its own controller?

00:09 <apritzel> as in: your display has its own framebuffer, which you access via the interfaces you listed?

00:09 <bunting> Uh I think so?

00:10 <apritzel> whereas the native support would put the framebuffer in system DRAM, and let the Allwinner display engine (DE) scan this out periodically and translate this to a signal via RGB, LVDS, MIPI-DSI or HDMI

00:10 <apritzel> which allows much quicker access to the framebuffer, plus the extra DE tricks like colour conversion and layers/transformations

00:12 <apritzel> if your display is more self-contained, you would not depend on display engine support, but would also not really be able to use the (Mali) GPU

00:13 <bunting> Then if I want to use GPU, 8080 interfacing or similar is useless?

00:20 <bunting> linux kernel drivers/gpu/drm/panel/ listed the LCD driver I chose so I thought that is the same thing on mainlining table

00:25 <apritzel> > GPU unusable with 8080 & friends interface: yes, that's my understanding

00:27 <apritzel> you would still need panel support, but that's a quite different kind of driver

00:27 <bunting> Then I should've chose one with LVDS or MIPI...

00:29 <apritzel> yes, but RGB aka parallel LCD would also work: then you have like at least 18 lines between the SoC and the panel (6 bits for each colour, minimum)

00:30 <apritzel> bunting: the H700 based handheld gaming consoles are probably pretty close to what you want (GPU works there), tokyovigilante has this working, and is in the process of upstreaming

00:31 <bunting> I guess 565 would be a hack pulling down unused lowest bits?

00:31 <bunting> I'll look for the H700 at vendor. Thanks for the advice

00:32 <apritzel> I think 565 is supported natively

00:33 <apritzel> there is also the T507, which is quite similar, and may have better availability

07:40 <warpme> apritzel, loki666: great work with h616 gpu dvfs! Last 3 days i tested 24h continuous hd tv playback (with gpu based deinterlacing) with huge number of gpu opp transitions and system was fully stabe :-) dvfs on gpu now works perfect. Next days i'll test on h6. Only thing a bit problematic is kernel oops at boot like this: https://termbin.com/apoq

11:29 <loki666> warpme: I'll check if I have the same on H700

18:23 <loki666> warpme: I do have the same kernel oops... https://gist.github.com/loki666/5f15c740294820566b087e1200ebfba4

18:23 <loki666> apritzel, any idea ?

20:46 <apritzel> warpme: thanks for the tests and the report! and loki666 thanks for the confirmation! So how easily can you reproduce this?

20:48 <apritzel> from a quick glance it looks like a tricky problem: basically this gate notifier is not really doing what I thought it would do :-(

20:50 <apritzel> as it does not gate the PLL output during the frequency change, but instead hopes to actually kind of reset the PLL, so that bigger frequency changes don't hang the loop

20:51 <apritzel> see the comment here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu_common.c#n64

20:52 <apritzel> since we use the gate bit, and not the actual enable bit for the newer SoCs, this trick sketched there does not work

20:53 <apritzel> oh wait, it is bit 31, not 27, I thought we changed that?

20:56 <apritzel> anyway, this trick looks dodgy, and maybe it does more harm than it helps on newer SoCs (since the manual explicitly warns against disabling the PLL at runtime)

20:58 <apritzel> warpme, loki666: do you guys have statistics on what the typical frequency changes are? This comment hints at that when the changes are too big, the PLL has trouble re-locking

20:59 <apritzel> but I think the swing is not that big for the GPU PLL anyway? At least much smaller than for the CPU PLL ...