RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

16 Nov 2021


      Hi Ramon,
...
-----Original Message-----
From: Ramon Fried rfried.dev@gmail.com
Sent: 2021年11月16日 13:57
To: Joakim Zhang qiangqing.zhang@nxp.com
Cc: Joe Hershberger joe.hershberger@ni.com; U-Boot Mailing List
u-boot@lists.denx.de; Ye Li ye.li@nxp.com; Patrick Delaunay
patrick.delaunay@foss.st.com; Daniil Stas daniil.stas@posteo.net;
Stephen Warren swarren@nvidia.com
Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
instead of starting EQOS
On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang qiangqing.zhang@nxp.com
wrote:
...
For EQOS ethernet, it will do phy_connect() and phy_config() when
start the ethernet (eqos_srart()), users need wait seconds for PHY
auto negotiation to complete when do tftp boot.
    phy_config()
            -> board_phy_config()
                    -> phydev->drv->config() // i.MX8MP/DXL use
realtek PHY
...
                        -> rtl8211f_config()
                                -> genphy_config_aneg()
                                        ->

genphy_restart_aneg()
...
// restart auto-nego, then need seconds to complete
To avoid wasting time, we can move PHY connection and configuration
from
eqos_start() to eqos_probe(). This patch also moves clock setting from
eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
no function change.
Tested-on: i.MX8MP & i.MX8DXL
Before:
u-boot=> run netboot
Booting from net ...
ethernet@30bf0000 Waiting for PHY auto negotiation to complete.......
done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
(313 ms) Using ethernet@30bf0000 device TFTP from server
10.193.108.176; our IP address is 10.193.102.192; sending through
gateway 10.193.102.254
After:
u-boot=> run netboot
Booting from net ...
BOOTP broadcast 1
DHCP client bound to address 10.193.102.192 (454 ms) Using
ethernet@30bf0000 device TFTP from server 10.193.108.176; our IP
address is 10.193.102.192; sending through gateway 10.193.102.254
How much time do you save exactly, Is it the ~140ms you show here at the
commit log ?
Exactly not. This time points to DHCP client bound to address, not the time this patch saves.
How can we evaluate the time we save? Please see the log:
Before:
    Booting from net ...
    ethernet@30bf0000 Waiting for PHY auto negotiation to complete....... done
    BOOTP broadcast 1
After:
    Booting from net ...
    BOOTP broadcast 1
And you need to check the related code:
drivers/net/dwc_eth_qos.c: phy_startup ->...->
drivers/net/phy/phy.c: genphy_update_link()
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/phy/phy.c#L22...
while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
    		/*
    		 * Timeout reached ?
    		 */
    		if (i > (PHY_ANEG_TIMEOUT / 50)) {
    			printf(" TIMEOUT !\n");
    			phydev->link = 0;
    			return -ETIMEDOUT;
    		}
if (ctrlc()) {
    			puts("user interrupt!\n");
    			phydev->link = 0;
    			return -EINTR;
    		}
if ((i++ % 10) == 0)
    			printf(".");
mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);
    		mdelay(50);	/* 50 ms */
    	}
We can see that one "." is about 500ms, so from the log, we save about 500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete auto-nego.
I also described this in the commit message, "users need wait seconds for PHY auto negotiation to complete when do tftp boot", may not quite clear, I will improve it.
Best Regards,
Joakim Zhang