Hi Ramon,

> -----Original Message-----
> From: Ramon Fried <rfried....@gmail.com>
> Sent: 2021年11月17日 12:20
> To: Joakim Zhang <qiangqing.zh...@nxp.com>
> Cc: Joe Hershberger <joe.hershber...@ni.com>; U-Boot Mailing List
> <u-boot@lists.denx.de>; Ye Li <ye...@nxp.com>; Patrick Delaunay
> <patrick.delau...@foss.st.com>; Daniil Stas <daniil.s...@posteo.net>;
> Stephen Warren <swar...@nvidia.com>
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
> 
> On Tue, Nov 16, 2021 at 1:02 PM Joakim Zhang <qiangqing.zh...@nxp.com>
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ramon Fried <rfried....@gmail.com>
> > > Sent: 2021年11月16日 18:45
> > > To: Joakim Zhang <qiangqing.zh...@nxp.com>
> > > Cc: Joe Hershberger <joe.hershber...@ni.com>; U-Boot Mailing List
> > > <u-boot@lists.denx.de>; Ye Li <ye...@nxp.com>; Patrick Delaunay
> > > <patrick.delau...@foss.st.com>; Daniil Stas
> > > <daniil.s...@posteo.net>; Stephen Warren <swar...@nvidia.com>
> > > Subject: 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.zh...@nxp.com>
> > > wrote:
> > > >
> > > >
> > > > Hi Ramon,
> > > >
> > > > > -----Original Message-----
> > > > > From: Ramon Fried <rfried....@gmail.com>
> > > > > Sent: 2021年11月16日 13:57
> > > > > To: Joakim Zhang <qiangqing.zh...@nxp.com>
> > > > > Cc: Joe Hershberger <joe.hershber...@ni.com>; U-Boot Mailing
> > > > > List <u-boot@lists.denx.de>; Ye Li <ye...@nxp.com>; Patrick
> > > > > Delaunay <patrick.delau...@foss.st.com>; Daniil Stas
> > > > > <daniil.s...@posteo.net>; Stephen Warren <swar...@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.zh...@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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fso
> > > ur
> > > >
> > >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> > > %2Fphy
> > > > %2Fphy.c%23L225&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.co
> m%
> > > 7C59322db
> > > >
> > >
> 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > > 7C0%7
> > > >
> > >
> C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > > MDAiLCJQIj
> > > >
> > >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=usRIR7L
> > > exBnk
> > > > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3D&amp;reserved=0
> > > >
> > > >                 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.
> >
> > Hi Ramon,
> >
> > I am not quite understand you mean, I only connect and config the PHY
> > in the MAC probe stage, yes, the link should be brought up, but startup
> PHY still in MAC open operation, just attaching PHY to MAC in MAC probe,
> seems not a problem. Is there any side effect?
> The link up is a side effect, the U-Boot device model works in lazy loading
> mode, where stuff is initialized only when needed. This works the same for
> all phys in all places.

Understand, thanks.

> Additionally, I'm not following how much time can you actually save, how
> much time passes between the probe() function and start() function in your
> setup ? how could it be seconds ?

Actually, Realtek PHY(RTL8211FDI) at my side, it needs about 3.5s to complete 
auto-negotiation.
If we connect and config PHY in probe(), it _may_ complete auto-nego when user 
start network (start()),
as you said, yes, if we start network quickly, we also need some time to wait 
it to complete. However, at least,
we can save some time compared to connect and config PHY in start(), where we 
need wait about 3.5s to complete
auto-nego.

> >
> > We did the same thing in FEC driver:
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> %2Ffec
> >
> _mxc.c%23L1522&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C4
> 3be042d
> >
> 7b6f427f406708d9a98188f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C
> >
> 637727196088131120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjo
> >
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bElnoO13
> uq0kg
> > t7yzIFwiMJpVH3L49SNF5dssplt%2Fjw%3D&amp;reserved=0
> True, that's an example that contradicts what I just said, but it's wrong.

OK.

Best Regards,
Joakim Zhang
> > Best Regards,
> > Joakim Zhang
> > > Thanks,
> > > Ramon

Reply via email to