08:48 <hexdump0815> xdarklight: good news - https://pastebin.com/6Xf3yD6v actually works ... i found out the problem after adding some logging into meson8b_init_rgmii_tx_clk and noticinf that they appeared if i manually modprobed but not on bootup, so the problem was that the driver is served from initrd and i did not rebuild the initird after installing the module to

08:48 <hexdump0815> test ...

08:49 <hexdump0815> xdarklight: with that patch in place i

08:49 <narmstrong> xdarklight: it’s a big issue with CCF, one consumer can change the rate and it can impact another clock depending on a pll and the only way is to use the clock protection

08:50 <hexdump0815> xdarklight: (wrong key) with that patch in place i'm ending up at the proper clock

08:50 <narmstrong> So the actual timeline is: eth is probed and selects mpll because clkdiv2 is not provide enough, sound probes and the DT changes the mppl2 rate but doesn’t update the eth clock because it can’t

08:51 <hexdump0815> @narmstrong: yes, this is the way it is

08:51 <narmstrong> So either we put 0 in the eth clockin of boards using audio or we protect the Ethernet clock but mpll2 won’t be usable by the audio stuff

08:52 <narmstrong> So first solution is the best to ensure CCF select clkdiv2 everytime

08:52 <hexdump0815> why two clocks are required for eth if it works well with only one defined?

08:53 <narmstrong> They are not « required », we simply tell Linux what clocks are hooked to the eth controller

09:11 <hexdump0815> ah - ok - thx for the explaination

09:28 <hexdump0815> xdarklight: narmstrong: final test - i can confirm now that with the two fixes from xdarklight i now have working ext phy eth with the sound modules compiled in as well :)

10:09 <xdarklight> hexdump0815: ah, that's very good

10:11 <xdarklight> narmstrong: OK, so I'll put on my TODO list to send a patch which temporarily disables the second input and to start a discussion with the CCF team

10:12 <xdarklight> narmstrong: also FYI, MPLL2 is only selected because the parent clock provides slightly higher precision. when it comes down to the RGMII TX clock at the bottom it's the same precision with both (FCLK_DIV2 and MPLL) parents: 2Hz off

10:14 <narmstrong> xdarklight: yes thx for analysis, seems this behavior changed recently

10:15 <xdarklight> narmstrong: at least we have confirmation that the MPLL2 input works fine. I think Yixun back in the days reported issues with it on AXG but the HW team said it "should" work fine

10:16 <narmstrong> xdarklight: indeed it’s a good validation !