[PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout

[Andreas Rehn]

sorry for the late response.

I run some test runs and maybe there is something with the phy itself
or something is missing on sun8i_emac_eth_stop/start?

if you have any patches/ideas to test - let me know!
maybe someone has an idea how I can try to force the Linux mainline driver
in the same situation?
just want to know if there is the same behavior.

test-scenario:
    download 10 times zImage and dtb over tftp,
    static ip, no reset, timeout = 1000
10 duplex half:
    soft reset time 0us with 3 tftp timeouts and recover
    lowest speed:   369.1 KiB/s
    max speed:      779.3 KiB/s
10 duplex full:
    soft reset time 0us with 0 tftp timeouts and recover
    lowest speed:   656.3 KiB/s
    max speed:      752.9 KiB/s
100 duplex half:
    soft reset time 0us with 1 tftp timeout and recover
    lowest speed:   1.6 MiB/s
    max speed:      2.7 MiB/s

100 duplex full:
        try1:       0us, 630000 us with 0 tftp timeout and recover
        try2:       1001000 us sun8i_emac_eth_start: Timeout
                    -> 5 times
                    -> reconnect cable
        try3:       382000us, 502000us with 0 tftp timeout and recover
        try4:       330000 us, 1001000 us sun8i_emac_eth_start: Timeout
                    -> 2 times
                    -> 192000 us
        try5:       power up with cable pluged in:
                    58000 us, 373000 us with 0 tftp timeout and recover
        try6:       354000 us, 494000 us with 0 tftp timeout and recover
        try7:       1001000 us sun8i_emac_eth_start: Timeout
                    -> 3 times
                    -> 1001000 us sun8i_emac_eth_start: Timeout, 626000 us
    next tries with fresh startup
        try8:       845000 us, 594000 us
        try9:       903000 us, 479000 us
        try10:      638000 us, 500000 us
        try11:      1001000 us sun8i_emac_eth_start: Timeout, 333000 us
        try12:      63000 us, 489000 us
    lowest speed:   1.6 MiB/s
    max speed:      2.7 MiB/s

when switching from 100 duplex half to full and try to run tftp download
for zImage and dtb
 try1:
    reset MAC done after: 0 us
    ethernet at 1c30000 Waiting for PHY auto negotiation to complete.........
TIMEOUT !
    reset MAC done after: 0 us
    ethernet at 1c30000 Waiting for PHY auto negotiation to complete.........
TIMEOUT !
 try2:
    reset MAC done after: 0 us
    Using ethernet at 1c30000 device
    TFTP from server 192.168.5.80; our IP address is 192.168.5.78
    Filename 'zImage'.
    Load address: 0x42000000
    Loading:
#################################################################
    #################################################################
    #################################################################
    ################################################################
    2.4 MiB/s
    done
    Bytes transferred = 3790520 (39d6b8 hex)
    reset MAC done after: 1001000 us
    sun8i_emac_eth_start: Timeout


Am Do., 20. Mai 2021 um 02:18 Uhr schrieb Andre Przywara <
andre.przywara at arm.com>:

> On Thu, 20 May 2021 00:10:47 +0200
> Andreas Rehn <rehn.andreas86 at gmail.com> wrote:
>
> > hey,
> >
> > sure. I give it a try tomorrow.
> > with 250 ms, for example, I ran into timeouts after the first tftp
> download.
> > after a manual retry, it works fine but retry is not a valid production
> > behavior.
>
> Just read the arch timer after the SOFT_RST write and after the first
> read of 0 again, and I got 17-18 ticks on my OrangePi Zero (H2+). So at
> 24MHz this is less than a *micro*second for the MAC to reset. So the 10
> ms are already plenty.
> Are you sure that it's this timeout value that is improving things for
> you?
>
> Cheers,
> Andre
>
> > greetings
> > Andreas
> >
> > Am Mi., 19. Mai 2021 um 23:45 Uhr schrieb Andre Przywara <
> > andre.przywara at arm.com>:
> >
> > > On Wed, 19 May 2021 21:42:08 +0200
> > > Andreas Rehn <rehn.andreas86 at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > > v3s emac soft reset tooks quit longer if autonegation is active
> > > > on 100 Mbit full duplex pairs what can result in
> > > > `sun8i_emac_eth_start: Timeout` error
> > >
> > > Mmmh, why the 500ms? Can you figure out how long it typically
> > > takes for you? By open-coding wait_for_bit_le32() and printing the time
> > > it took to flip the bit back?
> > >
> > > Happy to change this then when we have some data.
> > >
> > > Cheers,
> > > Andre
> > >
> > > > wait_for_bit_le32 polls register value each ms.
> > > > Increasing the timeout for setup do not effect current behavior
> > > > but reduces unexpected behaviors (e.g. timeouts on tftp download).
> > > >
> > > > Signed-off-by: Andreas Rehn <rehn.andreas86 at gmail.com>
> > > > ---
> > > >  drivers/net/sun8i_emac.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > > index 0e7ad3b0d4..23fd35f9e1 100644
> > > > --- a/drivers/net/sun8i_emac.c
> > > > +++ b/drivers/net/sun8i_emac.c
> > > > @@ -475,7 +475,7 @@ static int sun8i_emac_eth_start(struct udevice
> *dev)
> > > >       /* Soft reset MAC */
> > > >       writel(EMAC_CTL1_SOFT_RST, priv->mac_reg + EMAC_CTL1);
> > > >       ret = wait_for_bit_le32(priv->mac_reg + EMAC_CTL1,
> > > > -                             EMAC_CTL1_SOFT_RST, false, 10, true);
> > > > +                             EMAC_CTL1_SOFT_RST, false, 500, true);
> > > >       if (ret) {
> > > >               printf("%s: Timeout\n", __func__);
> > > >               return ret;
> > >
> > >
> >
>
>

-- 
Mit freundlichen Grüßen / kind regards
Andreas Rehn | Master of Engineering (M.Eng)