00:21 <apritzel> loki666: I might have found an issue with the power key, at least on the A523

00:23 <apritzel> in the A523 manual, it speaks of NMI controller reg +0x4, bit 31, controlling the "NMI input detect enable", and the NMI driver turns that off

00:25 <apritzel> if I replace the "0" in line 205 of drivers/irqchip/irq-sunxi-nmi.c with "BIT(31)", power key detection works for me, on the X96QPro+

00:26 <apritzel> maybe that the same issue on the H700? I don't have any device to test, though, but should be a rather easy check ...

07:40 <loki666> apritzel I'll try that thanks

11:12 <warpme> apritzel : i need yours brain with adding CLK_GMAC1, CLK_GMAC1_MBUS_GATE and CLK_GMAC1_25M in https://github.com/apritzel/linux/blob/e888372ebc40f8e8a5db281c9a17f5f3a05f7011/drivers/clk/sunxi-ng/ccu-sun55i-a523.c Mainline code vs bsp is so different for me that adding this my be will need me to to guess some things...and writing code by guessing is really bad idea...

14:22 <apritzel> warpme: well, give it a try. Actually the new AW clock code is now quite close to mainline, so you could try to correlate between mainline and BSP for GMAC0, then try to apply the GMAC1 bits to mainline

14:22 <apritzel> we don't care about those extra gates at 0xe04, at least for now, as they are ungated at reset

15:14 <warpme> apritzel : as ok - so...here is proposal: https://gist.github.com/warpme/e43fa01148fbc1c97b6bf482b3312f77

15:15 <warpme> i'm curious about L23

15:21 <apritzel> warpme: why do you doubt that? that's the divider, and 150 / 6 = 25, the math is the same for both MACs ;-)

15:22 <warpme> great. and what about rest: is it ok?

15:28 <BroderTuck> apritzel: You mentioned "patience of a monk" the other day. Good thing my nick here is basically "Friar Tuck" localized. The uSD cards have arrived

15:29 <apritzel> almost. Since you add a clock, you have to increase the number of supported clocks, which is currently defined to CLK_FANOUT2

15:30 <apritzel> warpme: and I think you need to add the other clock numbers as well

15:38 <apritzel> warpme: basically every clock you need to put into a DT needs to be exported in this header under the dt-bindings directory

15:39 <apritzel> BroderTuck: sounds also like a stability test for your H3 box, I guess, so keep your fingers crossed. How much DRAM does that box have?

15:40 <BroderTuck> apritzel: That one has 1GB

15:41 <apritzel> BroderTuck: because you would need to compile with make -j4, to get done still this year, but with only 1GB of DRAM you might run out of memory at some point

15:41 <warpme> apritzel : hmm - here i'm a bit lost: in bsp gmac1 dtsi: https://gist.github.com/warpme/7ef6e905cb37f6121f8ac27c8ef22dd4 I see only 3 clocks: clocks = <&ccu CLK_GMAC1>, <&ccu CLK_GMAC1_MBUS_GATE>, <&ccu CLK_GMAC1_25M>.....

15:52 <apritzel> warpme: for mainline you only need the gate clock, not the PHY one and not the MBUS one

16:00 <warpme> apritzel : "for mainline" - do you mean mainline gmac code? I want to play first with bsp code and my logic is that: bsp needs list of enabled clocks like list defined in bsp dtsi - not list of clocks mainline driver requires to work ok.... Is this wrong thinking?

16:15 <apritzel> ah, sorry to hear you are playing with the BSP :-( Why would you need any code changes then in the first place? Does Ethernet not work in the BSP?

16:22 <warpme> apritzel : oh no - my plan is 6.12.5 mainline with bsp gmac code :-)

16:23 <warpme> so from bsp i weill get only gmac-200 reated code

16:23 <apritzel> oh dear, then you are on your own, this sounds like a proper Frankenstein monster. Not even sure this works easily ...

16:25 <apritzel> warpme: for mainline to work it might be as easy as to enable the MBUS clock, or the 25M PHY clock in mainline - we don't touch both at the moment

16:33 <warpme> yeah - this might be bumpy road - but keeping in mind that: this is maybe new hw (gmac-200); mdio is maxio - i was thinking to give it try. Indeed alternative might be mainline gmac code - but because i don't know how gmac-200 hw is different from gmac hw already supported in mainline - i was thinking we have too many variables in equation (gmac-200 vs mainline gmac & maxio phy vs mainline supported phy). But I can do quick test with

16:33 <warpme> mainline - but to go this route i want to be sure that: if mainline gmac route will be non-working - this is not because of my wrong usage of mainline gmac (e.g. wrong clock setup; using dts/dtsi with wrong setup, etc). If you can guide me with trying mainline gmac - we can try....

21:33 <BroderTuck> apritzel: Welcome back. Thanks for linking to your 'cross' scripts, I went ahead and ressurected my old core2duo pc, put slack64 on it and now have aarch64 binutils and stage1 gcc on that machine. Haven't tested anything yet tho.

21:36 <apritzel> BroderTuck: ah cool, great to hear that it worked! you could test it by compiling U-Boot, which should be much quicker to compile than a kernel

21:46 <BroderTuck> That's a plan ... for tomorrow

21:48 <anarsoul> apritzel: see https://github.com/torvalds/linux/blob/master/drivers/clk/sunxi-ng/ccu-sun50i-a64.h#L11

21:49 <anarsoul> ccu-sun50i-a64.h includes dt-bindings/clock/sun50i-a64-ccu.h

21:50 <anarsoul> defining CLK_PLL_VIDEO0_2X and CLK_PLL_MIPI in both headers will result at least in a warning

21:51 <anarsoul> (I haven't checked if the kernel has -Werror for this warning)

23:32 <apritzel> anarsoul: I understand it's a double include, and I tested this before sending the email, and got no warning here. Then I changed the number in one (so it conflicts) and got the warning