04:10 <jernej> apritzel: difference is that you either need to write your own regmap find function like sun8i_dwmac_get_syscon_from_dev() in sun8i-dwmac or you can use helper like syscon_regmap_lookup_by_phandle()

08:26 <wens> syscon API has function to explicitly register a syscon attached to a device node. We should use that instead of letting the syscon API automatically create the regmap

08:27 <wens> the part I dislike about the syscon API is that the automatically created regmaps aren't related to any device

08:27 <wens> and it then becomes possible for the syscon API to create one, while your other driver creates another one that it itself uses.

08:29 <wens> and maybe rename the "syscon" property in the planes node to something more specific, like "allwinner,plane-mapping"?

10:21 <apritzel> seems like the Cubie A7Z has a USB-C controller chip, named ET7304Y in the schematic, that connects to the CC pins of the USB-C connector and also to I2C

10:21 <apritzel> does anyone have a datasheet for that one?

10:32 <buZz> ttps://etek.com.cn/upload/files/product/20250630/17512730724343324.pdf

10:32 <buZz> first google hit

10:32 <buZz> oh, actually duckduckgo hit :)

10:33 <buZz> seems not really a usb-c controller, but just USB-PD stuff?

10:34 <buZz> still nice of course

10:34 <apritzel> buZz: ah nice, thanks, Google just turned up the Radxa schematic and some Chinese merchant, nothing else

10:34 <buZz> yw , hth :)

10:34 <apritzel> well, something that deals with the CC pins for real, for a change

10:35 <buZz> yeah seems like it, PD 3.0 even

10:35 <buZz> up to 100W

10:37 <apritzel> I am pretty sure it's limited to 5V on this board, though, so it's more like 15W, I guess (5V@3A)

10:44 <buZz> btw, also https://www.digikey.at/en/products/detail/etek-microelectronics/ET7304/26227099

10:48 <maz> it'd be interesting to compare this ET7304 to a FUSB302...

10:49 <apritzel> ah, it's the "Y" at the end that put Google off ...

12:13 <MoeIcenowy> Maz: I saw some claim that ET7304 "can replace RT1715"

12:14 <MoeIcenowy> buZz: and I think a fully functional PD controller is just "USB Type-C controller"

12:14 <MoeIcenowy> because PD handles every advanced parts of Type-C

12:14 <MoeIcenowy> from high-voltage Vbus to USB 3.0 reverse

12:17 <MoeIcenowy> well ET7304 even has the vendor registers defined in https://chromium.googlesource.com/chromiumos/platform/ec/+/master/driver/tcpm/rt1715.c

12:18 <wens> apritzel: IIRC there are still issues with PD in Linux in general :(

12:20 <MoeIcenowy> and I think SBCs cannot run solely off PD (except fully-integrated PD power controller like CH224 is used)

12:20 <MoeIcenowy> because when switching power source capability the power will shut down for a while

12:20 <apritzel> exactly

12:21 <apritzel> so I guess they can negotiate a higher current, but that would be limited to 5V/3A

12:23 <apritzel> and I think we would get at least the role setting, so can properly select between USB device and host

12:52 <wens> looks like the gmac200 stuff is going to have to wait another cycle

12:57 <MoeIcenowy> apritzel: I think for 5V3A PD isn't necessary

12:58 <MoeIcenowy> fixed resistor can already erquire it

12:58 <MoeIcenowy> s/erquire/require

12:59 <MoeIcenowy> ( well my first device that runs mainline Linux and have a TCPM-compatible Type-C port is ... Pinebook Pro

14:50 <jernej> wens: ok, I don't have strong feeling about syscon. Let's go with allwinner,plane-mapping then.

14:51 <jernej> btw, I think every device which is referenced in syscon property, has to have syscon as compatible.

14:52 <apritzel> I think I've been told off for naming a property syscon before, by Rob, IIRC

14:54 <apritzel> jernej: I think it's best to post something to the list, to get the opinion of Rob and Krzysztof. At the end you need to get past them anyway ;-)

14:55 <jernej> sure, I was just looking for ideas before I delve into coding

14:55 <apritzel> jernej: so I just skimmed over it, but apart from that minor syscon detail the rest looked nice and sane to me!

14:57 <jernej> thanks!

21:12 <baltazar> hi! I'm trying to get sound working on a nanopi duo2. looking at device trees in images by friendlyarm, I see that the mainline dts are missing some stuff. e.g. &codec is defined but disabled in mainline, but okay in upstream's dt

21:14 <baltazar> this is the current patch I'm testing: http://0x0.st/KmiQ.diff but for some reason, once I set &codec's status to okay, the device no longer boots, nor does it print anything on the serial console. the last thing I see is u-boot's "Starting kernel ..."

21:15 <baltazar> any clues? how do I at least get some logs out of this?

21:25 <buZz> maybe remove that extra mmc0 you added in the patch?

21:25 <buZz> maybe its conflicting with something

21:26 <apritzel> baltazar: it's either disabled because the audio signal is just on headers, or because nobody bothered to send a patch

21:27 <apritzel> anyway it should work with that patch of yours, but hanging at this stage points to a different problem

21:28 <baltazar> buZz: I added that alias because otherwise it would randomly order mmc0 and mmc1, causing me to miss my root device. seems to have fixed it, but I might be misunderstanding how aliases work

21:28 <apritzel> did you change anything other than just enabling this node? are the DTs really only differing in this node?

21:29 <apritzel> yeah, that's an old problem. You can just use the DT that U-Boot ships ($fdtcontroladdr), and skip loading any DTB at all, then you get the aliases for free

21:31 <baltazar> apritzel: no, there are other differences, many of them unrelated to this issue (e.g. they don't define bluetooth in their dt, instead adding it from userspace) there's another relevant difference: they define a simple-audio-card that refers to these nodes, but I haven't added that yet. I assumed if it won't boot now, addin that won't help either but I might be wrong

21:32 <buZz> well, is your kernel even outputting anything to whatever interface you are looking on?

21:32 <buZz> it could be compiled without ttyS0 output as default msgs, and only output to hdmi?

21:33 <baltazar> buZz: normally, yes. if I leave &codec disabled, I see the full dmesg on my serial console during boot.

21:33 <buZz> with all the other changes you did on dts/dtb?

21:33 <apritzel> baltazar: so are you comparing some vendor kernel&DT against mainline? Did you try to get mainline to work just as is, without any changes?

21:34 <baltazar> mainline works and boots without changes, but it's missing the audio output I wanna get working. the patch I sent is what I'm applying to mainline right now

21:35 <apritzel> ok, that's odd. I don't think you need i2s2, do you? That's just for digital audio

21:35 <buZz> i2s is for running a external codec chip yeah

21:38 <baltazar> hm, then I'm not sure what I'm missing.

21:39 <apritzel> baltazar: do you have "earlycon" on your kernel command line? to see early output

21:41 <baltazar> oh, I had earlyprintk. I'll try with earlycon

21:46 <baltazar> cool, at least now I see a kernel panic :D

21:52 <buZz> yay! :)

21:55 <baltazar> welp, I'm not sure what to make of it :( From what I can tell, it tried to probe a driver, it failed, and it crashed during cleanup: http://0x0.st/KmiR.txt

22:03 <apritzel> baltazar: that looks like an interesting bug in the cleanup path indeed. That's a self-compiled kernel, isn't it? Do you have the DMA controller driver compiled in? CONFIG_DMA_SUN6I

22:05 <baltazar> apritzel: yup. (I'm using buildroot which sets up linux with the sunxi defconfig + some config changes on top of that)

22:05 <baltazar> whois apritzel

22:05 <baltazar> oops :P

22:08 <apritzel> it looks like it bails out either due to some missing prerequisite (like the DMA controller), or due to a -EPROBE_DEFER, so something not yet loaded

22:12 <baltazar> can't linux just dump core over serial or something?

22:17 <apritzel> tricky, but it gives you quite some information already, namely the stack and code

22:18 <apritzel> looks like component_driver->name is NULL

22:18 <baltazar> also what's with that 8 before <--- cut here? was it about to print something else and got panick'd in the middle or is that just how that normally looks?

22:21 <apritzel> that's scissors in ASCII art: 8<

22:21 <baltazar> ah /o\

23:07 <apritzel> baltazar: ah, I see the same thing as well now on my OrangePi Zero, when just enabling the codec node, same as you

23:08 <baltazar> oh well

23:12 <baltazar> hmm but e.g. sun8i-h3-orangepi-pc.dts has it enabled, even the same audio-routing config I'm trying to set. I wonder if that's working on that board

23:14 <apritzel> I would be guessing that's broken everywhere. It might depend a bit on the probe order, though

23:15 <baltazar> I assume order could make it not panic, but it still wouldn't work

23:16 <baltazar> I guess I should find out why the probe is failing in the first place

23:27 <apritzel> baltazar: so it's the call to snd_soc_register_card() at the very end of sun4i_codec_probe(), that calls snd_soc_bind_card(), which returns -EPROBE_DEFER. Then tragedy unfolds when it backs out

23:28 <apritzel> oh wow, it's a long list of things that get called in snd_soc_bind_card() ....

23:44 <baltazar> interesting. I tried converting those to modules, but apparently it's not just order. now it boots fine, but crashes the same way when I try to load it

23:48 <baltazar> wait no it's still order :P I just had to load sun8i-codec-analog before sun4i-codec

23:50 <baltazar> can't test if it's actually working atm but at least it shows up in alsamixer

23:52 <baltazar> many thanks for your help, I'll try to come up with an actual solution tomorrow but I'm off to sleep now, bye!

23:53 <apritzel> baltazar: right, I don't see the print from sun8i_codec_analog_probe() before it crashes

23:53 <apritzel> baltazar: I feel like it's an upstream that should be reported to the list (tomorrow)