imx6ul: Recent enet refclock changes breaks custom i.mx6ull board

[Stefan Wahren]

Hi Oleksij,

Am 06.03.23 um 10:47 schrieb Oleksij Rempel:
> On Mon, Mar 06, 2023 at 10:13:57AM +0100, Stefan Wahren wrote:
>> Hi Oleksij,
>>
>> Am 06.03.23 um 06:25 schrieb Oleksij Rempel:
>>> Hi Stefan,
>>>
>>> On Sun, Mar 05, 2023 at 11:16:17PM +0100, Stefan Wahren wrote:
>>>> Hi,
>>>>
>>>> we planned to submit our custom i.MX6ULL board [1] to mainline after release
>>>> of Linux 6.3-rc1, but the recent enet refclock changes breaks our Ethernet
>>>> phy:
>>>>
>>>> [    0.000000] imx:clk-gpr-mux: failed to get parent (-EINVAL)
>>>>
>>>> ...
>>>>
>>>> [   18.574595] SMSC LAN8710/LAN8720 2188000.ethernet-1:00: phy_poll_reset
>>>> failed: -110
>>>> [   18.581064] fec 2188000.ethernet eth0: Unable to connect to phy
>>>>
>>>> I narrow down the PHY issue to this first bad commit:
>>>>
>>>> 5f82bfced611 ("clk: imx6ul: fix enet1 gate configuration")
>>>>
>>>> The clock issues seems to be cause by the following commit. If i revert
>>>> 5f82bfced611 and 4e197ee880c24 or use Linux 6.2 everything is fine.
>>> It looks like in your kernel version are some missing patches. Can you please
>>> rebase your patches on top of this branch:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/log/?h=for-next
>> thanks for your fast reply. But i rebased my patches against Linux v6.3-rc1
>> since this was released yesterday and should contain all patches from Shawn.
> No, it is not. Related DTS changes are not included in to v6.3-rc1.

Sorry, i didn't noticed that Shawn already rebased his for-next changes 
on top of v6.3-rc1.

So, the problem is that your clk changes has been applied for 6.3, but 
the necessary arm changes will land in 6.4? :-(

>
>> I also changed the clockref in my DTSI file:
>>
>> https://github.com/chargebyte/linux/commits/v6.3-tarragon-v3
>>
>> Now the PHY issue disappeared and ethernet is working, but the
>>
>> imx:clk-gpr-mux: failed to get parent (-EINVAL)
> I need to take a look at it. It should not be critical.

I prepared a patch [1] to improve the debugging here:

[    0.000000] Entry 262144 != val 0
[    0.000000] Entry 16384 != val 0
[    0.000000] imx:clk-gpr-mux: val 0, num_parents 2
[    0.000000] imx:clk-gpr-mux: failed to get parent of enet2_ref_sel 
(-EINVAL)

It seems that val 0 is unexpected for the driver. Maybe it's worth to 
mention that we use an older U-Boot [2]. But Linux should make any 
assumptions here.

>
>> is still there.
>>
>>> and please rename IMX6UL_CLK_ENET_REF to IMX6UL_CLK_ENET1_REF_SEL in
>>> your dtsi.
>> Yes, this seems to be the issue in my case.
>>
>> Does this mean a Linux 6.3 kernel doesn't work with a i.MX6ULL Linux 6.2
>> devicetree?
> If I see it correctly. Since you do not have patch [1] related clock is not
> enabled by the fec controller. Since this PHY is not addressable without
> running rmii clock, the PHY can't be probed.
>
>> So there is no fallback?
> With [1] it should not be needed.
Maybe this patch comes too late (Linux 6.4) for some boards.
>
>> What about these other dtsi in Linux 6.3rc-1?
>>
>> $ grep IMX6UL_CLK_ENET_REF *
>> imx6ul-14x14-evk.dtsi:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> ..
>> imx6ul-kontron-bl-common.dtsi:            clocks = <&clks
>> IMX6UL_CLK_ENET_REF>;
>> imx6ul-kontron-sl-common.dtsi:            clocks = <&clks
>> IMX6UL_CLK_ENET_REF>;
>> imx6ull-dhcom-picoitx.dts:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> imx6ull-dhcom-som.dtsi:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> imx6ull-jozacp.dts:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> imx6ull-myir-mys-6ulx.dtsi:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
>> imx6ul-phytec-phycore-som.dtsi:            clocks = <&clks
>> IMX6UL_CLK_ENET_REF>;
>> mba6ulx.dtsi:            clocks = <&clks IMX6UL_CLK_ENET_REF>;
> It is nice to convert all of them to proper clock. But all of them are
> expected to work with [1].
>
> Can you please confirm it? Revert yourdtsi back to IMX6UL_CLK_ENET_REF
> and include [1]?

I rebased all changes on top of Shawn's branch and reverted to 
IMX6UL_CLK_ENET_REF [3]. So yes, i confirm that Ethernet works in this case.

Best regards

[1] - 
https://github.com/chargebyte/linux/commit/74a883d3ca4960a7d178d4a184daf9856600ca14
[2] - https://github.com/chargebyte/U-Boot/tree/v2020.04-in-tech
[3] - https://github.com/chargebyte/linux/tree/v6.4-shawnguo-tarragon

>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next&id=8940c105273fcde00a60023f68f8a5b75e1df0cc
>
> Regards,
> Oleksij