12:50 <mntmn> hmm i somehow managed to make etnaviv not render anymore in conjunction with dcss. i wonder if it is the version of tf-a

12:50 <mntmn> framebuffer works but as soon as gpu is involved, only blackness... (imx8mq)

12:51 <marex> mntmn: mode switch problems ?

12:51 <mntmn> marex: possibly

12:52 <marex> mntmn: roll back to latest working version ?

12:52 <marex> which you surely tagged when you built that one ? :)

12:53 <mntmn> hehe yeah well i have backups of everything

12:53 <mntmn> i didn't pull any new code... was just playing with sleep/wake again yesterday (suspend to ram)

12:54 <mntmn> but i was using the glitchy LCDIF to test that with etnaviv and it worked. then went to wire up dcss again and it fell apart

12:54 <mntmn> many moving parts.

13:00 <mntmn> ok, i must have messed up something in the kernel. rolling that back fixes it

13:03 <marex> mntmn: so, git bisect :)

14:16 <mntmn> yeah... etnaviv+dcss is broken for me now on current linux+mesa git. (black screen)

14:16 <mntmn> bisect it is

15:01 <mntmn> this is so frustrating, i'm thinking to just stay with the old version and never update again...

15:07 <lynxeye> mntmn: Oh, so you are switching to building a IoT device now? ;)

15:08 <lynxeye> I agree those things can be quite frustrating as long as there are still so many moving parts when not everything is upstream.

15:09 <mntmn> yeah ;)

15:09 <mntmn> well, the parts that i'm dealing with are upstreamed i guess

15:10 <mntmn> but they just don't work together... something was changed in drm that makes dcss not work at least with the dsi/edp bridge in between

15:10 <mntmn> or, it works in the latest git tip of linux with the framebuffer, but not with etnaviv anymore

15:14 <lynxeye> hm, only relevant difference between framebuffer usage and usage with etnaviv would be memory tiling.

15:14 <lynxeye> But if that got broken I would expect a garbled display, not a black screen.

15:15 <mntmn> yeah, i'm not sure yet what is going on. i'm doing a proper bisect now from the last known good version

15:17 <mntmn> but there's one wart in that i so far need a small patch to dcss to make it work at all in my bridge configuration: https://source.mnt.re/reform/reform-system-image/-/blob/reform2-upstreaming/reform2-imx8mq/template-kernel/patches/0003-dcss-fix-attaching-to-sn56dsi86-bridge.patch

15:17 <mntmn> i know that this patch is improper but i also don't understand drm well enough to do this properly

15:18 <mntmn> there's a range of kernel commits between the working version and the current version where this patch leads to a lockup in drm_bridge_hpd_enable+0x50/0xa0

15:18 <lynxeye> mntmn: Yep, something I have on my list of things to look at. Unfortunately free time is limited right now. But at least I got the first part of the PCIe refclock output upstream.

15:19 <mntmn> lynxeye: oh, you did?

15:19 <mntmn> lynxeye: do you have a link maybe?

15:20 <lynxeye> mntmn: https://lore.kernel.org/linux-arm-kernel/20210125174135.1223680-1-l.stach@pengutronix.de/

15:21 <lynxeye> This allows to configure and reference the clock from the DT. PCIe controller side to select internal refclock is still missing.

15:22 <mntmn> lynxeye: that's cool, thanks!!

17:22 <mntmn> ok the breaking change is > drm/bridge: ti-sn65dsi86: Read EDID blob over DDC

17:23 <mntmn> bisected 8008 commits...

17:25 <mntmn> 58074b08c04af1817ab34be986a80279e7267d07

17:26 <mntmn> looks like it reads some wrong mode data and overwrites the one that i specified in the panel node

17:32 <mntmn> yeah. latest kernel tip works with that commit reverted. oof