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

On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang qiangqing.zhang@nxp.com wrote:

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

NACK. Hi Joakim. It's currently working like that for all network drivers, it's not specific What you're currently suggesting is that the link will be brought up automatically for all users, even if they're not interested in network booting. That won't work. Thanks, Ramon