01:08 <apritzel> iscle: I think I fixed it: DMA is always built in for sunxi, but only enabled if the DT DMA properties are found and use_dma is not set to 0 on the command line

01:09 <apritzel> need to test that tomorrow ...

07:56 <gamiee_> apritzel : iscle was there last time 2 days ago, let's hope he will arrive soon

09:14 <gamiee> also, he seems to use web irc. If he will not come here in few days, I will try to send him an email

13:20 <iscle> gamiee_: i'm here! yes, I use the webchat, is there any linux-friendly client for this?

13:21 <iscle> as for the USB DMA, I played a lot with it but could not really see if it was indeed working or not, the transfer speeds and CPU usage did not change... It was weird, and the user manual does not really give much information on it. Most of the work I did was by looking at tina code and trial/error

13:22 <iscle> I did not clean it up or submit it because I could not really test it

13:24 <iscle> apritzel: I can take another look at USB DMA code if you think it's of interest for people, and try to figure out what was wrong with it and eventually merge it

13:24 <apritzel> iscle: yeah, I got kernel oopses when testing USB mass storage with that, swiotlb related

13:25 <apritzel> iscle: but thanks for the info, I wasn't sure if it was supposed to work

13:27 <apritzel> iscle: an IRC client for Linux you mean? There are more than you can probably count ;-) I use hexchat, for instance, some people also use pure text GUI clients in a terminal

13:27 <iscle> apritzel: I mainly abandoned it because of the lack of info and me not knowing how to properly test/benchmark it. However, I do really want to get it working, as some of my projects would greatly benefit from it. Maybe I can give it another go when I have some more time

14:39 <gamiee_> iscle : I would definitely have usage for USB Gadget DMA, and I can test it on H618

22:22 <Lightsword> apritzel, I think I managed to get runtime phy selection working: https://github.com/jameshilliard/linux-h616/commits/acx00

22:24 <apritzel> Lightsword: and who will set that boolean property?

22:25 <Lightsword> apritzel, like this: https://gist.github.com/jameshilliard/7c993c356e29237e1ced307e0fd35538#file-sun50i-h616-whatsminer-dts-L137

22:49 <apritzel> so it's the code in sun8i-emac that queries the efuse, and then hunts for a PHY node with respective boolean property?

22:53 <apritzel> that doesn't look it would be accepted, tbh, your commented phys list with phy-names looks more promising

23:11 <Lightsword> apritzel, yeah, that's more or less how it works, I could tweak it to use the phy-names list instead for the selection logic if that makes more sense

23:13 <Lightsword> apritzel, the logic is conditional upon the ac300 nvmem value existing in the device tree so it shouldn't cause issues for existing devices

23:14 <Lightsword> the hunt for the boolean property approach I figured was more similar to how some of the stmmac mdio address scanning modes work, except it scans based on a boolean instead of the mdio device being on the bus

23:16 <apritzel> the nvmem reference in the MAC node and the respective code in the MAC driver to query this sound good, but the rest won't fly on the list

23:17 <apritzel> it's a shame Ethernet DT nodes only allow a single PHY - using phy-handle, not phys (like HDMI or USB)

23:19 <apritzel> so not sure using the nvmem content to select one of two PHYs (enumerated in the PHYs property) would be accepted, also since both apparently use the same MDIO address

23:24 <Lightsword> apritzel, so luckily the ac200 can use MDIO address 1 or 0, the ac300 needs MDIO address 0 however, so we can deconflict them by simply using MDIO address 1 always for the ac200 and MDIO address 0 for the AC300

23:29 <apritzel> isn't 0 the broadcast address, so any PHY answers on this? And the PHY address to use must actually be programmed into the I2C device (EPHY_CTL register at 0x6000[8:4])

23:31 <Lightsword> apritzel, I think address 16 might be the broadcast address, well at least on the AC300 it seems

23:35 <apritzel> ah, no, I now remember: MDIO address 16 is to reach the AC300 control registers, the PHY is apparently on a customisable address "~PKG[2:0]", defaulting to 0

23:35 <apritzel> (customisable at packaging time, so out of reach for us)

23:39 <Lightsword> apritzel, I'm having uboot initialize it like this at the moment: https://github.com/jameshilliard/u-boot/commit/5ba877e729a7082deb54b5708427942f28fdebb9

23:41 <apritzel> I hate to break it to you, but this U-Boot code is completely unacceptable, that's probably based on jernej's early HACK back in the days, that he used to just confirm it's working?

23:43 <apritzel> U-Boot should use the same DT approach as Linux, those hard coded clocks and I2C symbols are just for the SPL

23:43 <Lightsword> apritzel, yeah, I'm aware, it's kinda a combination of a bunch of random hacks I found on github that I managed to get working

23:44 <Lightsword> I figure best to figure out the device tree structure for Linux then port it to uboot.

23:47 <apritzel> yes, definitely