05:02 <Darkmatter66> narmstrong, Ok i applied the patch locally and it definitly fixed the reboot issue, although i still occasionally get stuck during boot on the drm line https://0x0.st/zIfJ.txt

05:03 <Darkmatter66> narmstrong, anything i can enable to get more info about this issue /

05:03 <Darkmatter66> narmstrong, ?

09:41 <narmstrong> Darkmatter66_: no idea for this only

10:16 <chewitt> I've not seen that behaviour in any of my testing

11:00 <Darkmatter66> chewitt, I've been seeing this bug for months(since I started testing mainline which at that time was 4.17 I think)

11:00 <chewitt> does is actually stop the kernel at that point .. or just stop dumping output to the console?

11:02 <Darkmatter66> chewitt, it's hard to trace since it happens sporadically, but most of the times it happens when i hard reset the board (by cutting the power from the power supply) or by running "echo b > /proc/sysrq-trigger"

11:02 <Darkmatter66> chewitt, yes it stops the board at this point and I have to cut the power off and on again for it to boot again

12:57 <warpme_> https://www.irccloud.com/pastebin/TCguC0dW/

12:57 <warpme_> is there missing prerequisite patch to apply?

12:58 <warpme_> narmstrong: guick Q: I'm trying to apply https://patchwork.kernel.org/patch/11261751/ over 5.4 and receiving like above

12:59 <warpme_> narmstrong: quick Q: I'm trying to apply https://patchwork.kernel.org/patch/11261751/ over 5.4 and receiving like above

12:59 <warpme_> geez - sorry for mess with irc client....

13:13 <narmstrong> warpme_: I'm basing my patch on the media next tree, so probably yes

13:14 <narmstrong> https://www.irccloud.com/pastebin/Whgd0Mix/

13:20 <warpme_> is it possible to create patch with 5.4 as baseline?

13:24 <warpme_> Q is obviously not about creating patch task (as this is trivial). It is rather: is it possible to have this series working over mainline 5.4 instead of media-next? I'm asking as I have cedrus/hantro patches based on 5.4 mainline....

18:28 <warpme_> narmstrong: may you pls share git url for media-next tree you are using as baseline for https://patchwork.kernel.org/patch/11261751/ FYI: I got working this series atop of 5.4 mainline with current FFmpeg master ffplay but can't get working with zero-copy with EGL_LINUX_DMA_BUF_EXT. Maybe issue is missing v4l2 code changes present in media-next tree but not present 5.4 mainline? Just want to test this

18:28 <warpme_> hypothesis...

18:35 <narmstrong> warpme_: https://github.com/superna9999/linux/commits/amlogic/v5.6/vdec-g12a

18:36 <narmstrong> warpme_: how do you display with ffplay ?

19:45 <xdarklight> Darkmatter66: do you still have the .dts snipped you used to get that error: http://lists.infradead.org/pipermail/linux-amlogic/2019-November/014597.html

19:48 <xdarklight> I don't see how the "no phy at addr -1" error is possible with the &ethmac node from GXBB Nexbox A95X, so I'm interested in the .dts snippet or additional kernel errors which you didn't include in that email

19:59 <Darkmatter66> xdarklight, I don't have the snippet right now but I can re-create it, give me a few minutes

20:13 <Darkmatter66> xdarklight, hmmmm, I re-created the device tree and now it works !

20:14 <Darkmatter66> xdarklight, most likely i did something wrong the first time , or my recent tree rebasing solved the issue

20:33 <xdarklight> Darkmatter66: great, I recommend the way A95X defined the Ethernet controller because it doesn't use the deprecated GPIO definition. P201 only uses the deprecated way because we don't know which PHY it uses and thus we don't know the PHY address... meaning we can't use the new way of describing network

20:33 <xdarklight> thanks for trying again :)

20:34 <Darkmatter66> xdarklight, happy to try