20:52 <DavidHeidelberg[m]> <lumag> "Got Nexus 7 LTE (deb) btw..." <- Congrats, check my repository for qcom-apq8064-v5.10 or -next (due in -next dsi currently fails)

20:52 <DavidHeidelberg[m]> * Congrats, check my linux repository for qcom-apq8064-v5.10 or -next (due in -next dsi currently fails)

20:53 <Marijn[m]> David Heidelberg: Curious about that DSI failure 😉

20:55 <DavidHeidelberg[m]> Due to some recent dsi rework (mainline and next affected) logs https://paste.sr.ht/~okias/67154608cf73e367d03b26c407d3c62c5835a2b6

20:56 <DavidHeidelberg[m]> I already tried fix with +1/for 28nm-8960 which was missed in refactoring, but it makes it crash at boot

20:57 <DavidHeidelberg[m]> Also ignore irq oopses, they're eith me looong time :P

20:58 <Marijn[m]> Those legacy clock name warnings are curious. Someone should fix them before _clk prefixes are not ignored anymore

20:59 <Marijn[m]> Interesting stuff anyway. It's trying to reparent dsi1 clocks to dsi0...

20:59 <DavidHeidelberg[m]> I prefer to not touch it, since due apq8064 being kinda unmaintained, it can cause issues somewhrere. I removing _clk from block to block, patch by patch as I can test it

21:00 <Marijn[m]> I just sent a bunch of patches yesterday/today to deal with VCO ref clocks, maybe those are worth applying and testing. They shouldn't fix this though

21:00 <Marijn[m]> Do you have a `/d/clk/clk_summary` by the way?

21:00 <DavidHeidelberg[m]> For dsi I tried to remove it, but it didn't had effect on the issue

21:01 <Marijn[m]> Heh the clock graph at the top of the file anyway says DSI1, then intermixes dsi1 and dsi0 clocks...

21:01 <DavidHeidelberg[m]> > CLK 5.10: https://pastebin.ubuntu.com/p/8JWjzWmBb7/ (dsi1* tree);

21:01 <DavidHeidelberg[m]> X

21:01 <DavidHeidelberg[m]> x

21:01 <DavidHeidelberg[m]> > CLK -next: https://pastebin.ubuntu.com/p/gk6H7DHPbB/ (for some reason I see just 3 entries for dsi0, which aren't present in 5.10)

21:02 <DavidHeidelberg[m]> Fix for this should be adding +1 to clk name in dsi 28nm 8960, but as I said, that caused another fail

21:02 <Marijn[m]> Oh, I need a Ubuntu account to see those?

21:02 <Marijn[m]> Maybe I still have one, 'sec

21:05 <Marijn[m]> It looks curious but it's not that bad, the mmcc driver simply starts counting from 1 🤦‍♂️

21:06 <DavidHeidelberg[m]> Marijn[m]: U shouldn't need acct.

21:07 <Marijn[m]> `You need to be logged in to view this paste.` - but I found an acc already

21:07 <DavidHeidelberg[m]> Damn, I dont have accnt and I see it.. Maybe because I uploaded

21:09 <DavidHeidelberg[m]> Whrn the fix is applied it goes trough init and after approx. 200s of black screen it diesnon some dsi_init_irq

21:09 <DavidHeidelberg[m]> * Whrn the fix is applied it goes trough init and after approx. 200s of black screen it dies on some dsi_init_irq

21:09 <DavidHeidelberg[m]> * When the fix is applied it goes trough init and after approx. 200s of black screen it dies on some dsi_init_irq

21:10 <bamse> robclark: https://hastebin.com/afagewaliw.yaml

21:11 <bamse> robclark: phys->hw_ctl in the loop in dpu_encoder_trigger_kickoff_pending() is NULL

21:12 <bamse> robclark: turns out this is the same problem i had back in july, but i guess the timing shifted in my favour...for a while

21:12 <Marijn[m]> David Heidelberg: The fix being fw_devlink=permissive? The curious thing is that 5.10 registers a dsi1 PLL only, 5.14 registers a dsi0 PLL. If I read the code that `dsi_phy` at `4700300` should receive index 0 and the last commit was made 5 years ago

21:12 <bamse> robclark: "wrong" channel...

21:12 <DavidHeidelberg[m]> Permissive is for something else

21:13 <DavidHeidelberg[m]> Yeah the issue is enueration. But with that fixed, it still fails on dsi_init_irq later

21:13 <Marijn[m]> David Heidelberg: Ah, I read over that +1 message. Still strange, the ID shouldn't matter afaik as long as the address is correct. There's no reliance on global clock names (using this number) either, it's just a phandle

21:14 <DavidHeidelberg[m]> So when enumeration is fixed (it is dsi1 again) it still dies and not sure if something related to refactoring touching naming or something completely unrelated

21:15 <DavidHeidelberg[m]> Marijn[m]: 8960 has somewhere in mmcc or ... hardcoded dsi1 ;)

21:15 <Marijn[m]> Yeah, the +1 comes from 5.10

21:16 <DavidHeidelberg[m]> 5.10 is example or working display/drm

21:16 <Marijn[m]> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c?h=v5.10#n499 This was lost - but I still have a feeling it shouldn't make a difference for anything than the name.

21:17 <Marijn[m]> So with the +1 in there, do you get a clock tree like 5.10 again, and are the reparenting errors gone?

21:17 <DavidHeidelberg[m]> I get irq fails in dsi_init_irq after 200s wait with black screen :D

21:18 <DavidHeidelberg[m]> Give me a mail, I'll resend u dmesg

21:18 <Marijn[m]> `marijn.suijten@somainline.org`

21:21 <DavidHeidelberg[m]> U should have it in mailbox Marijn

21:23 <Marijn[m]> David Heidelberg: Yep, thanks! Reading it now. Good to see Dmitry on the `+ 1` case already.

21:25 <DavidHeidelberg[m]> Yeah, but .. it triggers some apq8064 related bug or rework broke it also elsewhere :'(

21:31 <Marijn[m]> David Heidelberg: Have you tried to bisect this already? That's what I'm leaning towards too (maybe check mdp4 first), piecing together the interrupt this is `DSI_IRQ_MASK_ERROR | DSI_IRQ_CMD_MDP_DONE | 0x4`. Have you enabled more debugging before to see if anything is waiting for completion by means of another interrupt?

21:32 <DavidHeidelberg[m]> No, I didn't. I had problem that sometimes it won't reboot, so no pstore dmesg for me

21:33 <DavidHeidelberg[m]> I'll try enable some additional debug, I just hoped it'll be something easily spotable in thr code

21:33 <Marijn[m]> Hmm, tricky. Seeing as Dmitry has the device now I'll let him do the debugging, he's more fluent around the DSI code than I am :)

21:33 <DavidHeidelberg[m]> * I'll try enable some additional debug, I just hoped it'll be something easily spotable in the code

21:34 <Marijn[m]> David Heidelberg: Well everything (in the forwarded dmesg) seems fine until it comes up with an error-IRQ 200+ seconds in

21:34 <DavidHeidelberg[m]> lumag is Dmitry, right? :D

21:35 <Marijn[m]> Yep :)

21:35 <DavidHeidelberg[m]> Oh. I was suprised that two people got n7 recently :D

21:36 <DavidHeidelberg[m]> Guessing irc nicks isn't my strong skill :))

21:36 <DavidHeidelberg[m]> * Assigning irc nicks to the real names isn't my strong skill :))

21:39 <DavidHeidelberg[m]> Anyway, thanks for checking it. I believe soon -next gets better than original 4.11 kernel