03:41 <junari> Now we need to merge all the code you two have made for a523 into one

04:57 <jernej> apritzel: nice, but do they actually work?

09:43 <Jookia> nice!

11:06 <apritzel> junari: I've sent a somewhat preliminary A133 U-Boot support series to the list, I plan to do something similar for the A523 in the next days

11:07 <apritzel> would be probably marked as RFC, as the DT bindings are not finished yet

13:02 <maz> apritzel: what GIC version does this A523 has?

13:02 <maz> have*

13:05 <maz> ah, GIC600. don't think I have this one in my collection yet...

13:09 <loki666> apritzel I have news about the USB OTG issues on h616/h700

13:09 <loki666> The patch is not needed in the end

13:10 <loki666> All that is needed is to remove the phy0 ref in ehci0/ohci0 nodes as it's usbotg that takes control over it

13:11 <apritzel> loki666: well, but that's a broken hack, it's wrong, and it breaks U-Boot

13:11 <loki666> After just have a USB gadget interface enabled, USB port acts as expected both in peripheral and host mode and charger (if battery)

13:12 <apritzel> maz: yes: Arm GIC-600 r1p4 GICv3 interrupt controller, LPIs, one ITS

13:13 <apritzel> loki666: both the OTG and host controller share that PHY, so that must be expressed in the DT, by both nodes pointing to the PHY node

13:13 <loki666> Well then I have no other ideas, currently the issue is that both ehci0/ohci and usbotg fight for phy0

13:13 <apritzel> I know, but from a quick glance I believe the patch you mentioned would solve that?

13:15 <loki666> No it was causing races conditions issues and by going behind the back of core phy it was changing the vbus phy without phy core accounting for it

13:15 <loki666> Leading to more issues

13:18 <apritzel> I see, but I think it was the first time I was seeing some solution going in the right direction.

13:19 <apritzel> I investigated that a few years back, and just figured that it's not an easy problem to solve back then. So maybe it's worth basing something on that patch, then?

13:21 <loki666> I also found a ML thread that states that with an USB OTG port, host is only supposed to works when gadget interface is enabled

13:22 <loki666> Pointing to that ehci is "slave" to musb and doesn't own the phy

13:22 <loki666> The issue is that h616 musb is crap

13:23 <loki666> If it could deal with host functionality we wouldn't have these issues

13:24 <loki666> https://lkml.org/lkml/2018/4/20/504

13:25 <loki666> I have a simpler patch that works and enable host without patching .dtsi and works as expected

13:26 <loki666> https://gist.github.com/loki666/fcbac458cfbfc712910518e1f69e6da2

13:29 <apritzel> Allwinner MUSBs were always bad, that's why they introduced another host interface and this multiplexer (with the H3 in 2014, I think)

13:30 <apritzel> where does this patch come from?

13:31 <loki666> Mine

13:31 <loki666> After lot of debugging what was going on

13:32 <loki666> And a bit of the wirenboard patch

13:57 <apritzel> loki666: interesting, the patch looks intriguing, but I know too little about the details to judge it. Maybe post it to the list to see what people have to say?

14:09 <loki666> Ok I'll do that

14:39 <loki666> apritzel: https://lore.kernel.org/all/20170306223449.21404-3-icenowy@aosc.xyz/T/#m4c8c74306d79e2b53d549ae1c7b1e03385489203

14:39 <loki666> Patch 3 also mention about not binding phy0 to ehci0

14:44 <loki666> And that's one of the root issues if we bind PHY to ehci0, there is always a vbus on the port

14:45 <loki666> Because that's what a host USB port wants... Power the peripheral connected

14:46 <loki666> But in otg you need to wait to be sure to be really connected to a peripheral before sending vbus

14:58 <apritzel> I know, I was the one to break it ;-) https://lore.kernel.org/linux-arm-kernel/20190620010127.12071-1-andre.przywara@arm.com/

14:59 <apritzel> but I think it's a shortcoming of the PHY driver, and you might have just fixed it ;-)

15:12 <loki666> Ok let's continue that in mailing list then

15:12 <loki666> I'll prepare a patch

15:33 <apritzel> many thanks!

15:35 <loki666> Because my patch is still lying to core PHY about being powered on for phy0

15:39 <apritzel> hopefully we get some feedback from the maintainers ...

16:20 <jernej> apritzel: finaly some T527 manual in Radxa Cubie A5E package. Look at SRAM map generates annoyance :)

16:45 <apritzel> jernej: nice try to trick me into downloading that crap ;-)

16:46 <jernej> did it work? :D

16:57 <apritzel> well, I clicked on that A5E BSP package, in the hope it would be small, but that doesn't work apparently: some mega failure, it looks like

16:58 <apritzel> not trying anymore, hoping for someone to upload it :-)

16:58 <jernej> it's .repo content, after that you have to run repo sync -l command

16:58 <jernej> but it contains many interesting repos, some of them I see for the first time

17:02 <jernej> apritzel: anyway, can you confirm all 8 cores works as expected on T527?

17:05 <apritzel> ah, yes, it looked like: I taskset'ed the shell without problems, and in general I would expect the kernel to crash when something is wrong with the secondaries

17:14 <jernej> apritzel: so all good?

17:14 <apritzel> yep, looks like it, good job!

17:14 <jernej> great!

19:10 <loki666> I tried the a133p SDK for my handheld... Compilation crash on 2nd package

19:10 <loki666> Out of 7898 😂

19:10 <loki666> Gave up there

19:11 <loki666> And the cheap bastards didn't provide a SD card with a running system

19:13 <loki666> I might just let in the drawer until they provide an image to flash somewhere

21:46 <loki666> apritzel: should I split the patch in two, I see two distincts parts, the override of the phy0 regulator, and the override of dr_mode

21:47 <apritzel> split as much as you can, yes. Definitely split DT and code, but you probably knew that already ...

21:53 <loki666> yes, but reading the ML thread you linked above, I see that wens reported that having phy0 in both hci and otg was working for him ? https://lore.kernel.org/linux-arm-kernel/CAGb2v67woLtn4bdD8YbCN9CyLPm_9r9+wd_Cxp8AUeVed0O-pA@mail.gmail.com/

21:55 <loki666> that can't be right, because as soon as you link phy0 to a HCI, it's regulator is on, so if you plug a cable connected to another host (ie: for gadget mode) you ll blow the vbus reg of your board

21:56 <loki666> and no matter what musb try to do with the phy0, il will stay powered because of HCI

22:06 <apritzel> loki666: well, powering from both sides in indeed against the spec, but often works anyway, as long as at least one side is reasonable (some laptop, some instance)

22:13 <loki666> looks like my PC wasn't

22:50 <apritzel> sorry to hear that! But it was the A133P board that took damage, not the PC?

23:01 <GAMG> Hi there. Anyone been able to get panfrost working on OrangePi Zero 2 on newer kernels? I tested both meta-sunxi project (6.6) and also built my own kernel (6.12.9). non of them work (system just freezes upon loading panfrost). Official debian image works fine though(6.1). Any help would be much appreciated.

23:23 <apritzel> GAMG: that's probably because of the missing power domain driver. Here is an attempt: https://lore.kernel.org/linux-sunxi/20240225160616.15001-2-andre.przywara@arm.com/

23:24 <apritzel> but IIRC this has issues

23:28 <loki666> apritzel: it was one of H700 board, and luckily the one with a second host port, so no functionality lost, as peripheral is still working and very safe to use with a host now

23:31 <GAMG> apritzel: thanks. I will give it a try.