From: Andreas Rehn <rehn.andreas86@gmail.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: hdegoede@redhat.com, Jagan Teki <jagan@amarulasolutions.com>,
icenowy@aosc.io, u-boot@lists.denx.de
Subject: Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout
Date: Fri, 21 May 2021 22:14:00 +0200 [thread overview]
Message-ID: <CAPmT5DdF1v=BOR6SCMZvnqr3aE1yx94a1+904DeAfks2VbDXJg@mail.gmail.com> (raw)
In-Reply-To: <20210520011804.208c9b5c@slackpad.fritz.box>
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@1c30000 Waiting for PHY auto negotiation to complete.........
TIMEOUT !
reset MAC done after: 0 us
ethernet@1c30000 Waiting for PHY auto negotiation to complete.........
TIMEOUT !
try2:
reset MAC done after: 0 us
Using ethernet@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@arm.com>:
> On Thu, 20 May 2021 00:10:47 +0200
> Andreas Rehn <rehn.andreas86@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@arm.com>:
> >
> > > On Wed, 19 May 2021 21:42:08 +0200
> > > Andreas Rehn <rehn.andreas86@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@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)
next prev parent reply other threads:[~2021-05-21 20:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 19:42 [PATCH 0/6] arm: sunxi: v3s: add ethernet support Andreas Rehn
2021-05-19 19:42 ` [PATCH 1/6] dts: sunxi: add licheepi-zero-dock Andreas Rehn
2021-05-19 21:42 ` Andre Przywara
2021-05-19 21:55 ` Andreas Rehn
2021-05-19 19:42 ` [PATCH 2/6] clk: sunxi: v3s: Implement EMAC clocks/resets Andreas Rehn
2021-05-19 21:43 ` Andre Przywara
2021-05-19 19:42 ` [PATCH 3/6] clk: sunxi: v3s: fix tabs / spaces Andreas Rehn
2021-05-19 21:43 ` Andre Przywara
2021-05-19 21:59 ` Andreas Rehn
2021-05-22 23:17 ` [PATCH v2 " Andreas Rehn
2021-05-26 23:16 ` Andre Przywara
2022-01-15 17:36 ` Sean Anderson
2021-05-19 19:42 ` [PATCH 4/6] net: sun8i-emac: add v3s pinmux setting Andreas Rehn
2021-05-19 21:44 ` Andre Przywara
2021-05-22 23:22 ` [PATCH v2 4/6] net: sun8i-emac: add v3s variant Andreas Rehn
2021-05-25 6:53 ` Ramon Fried
2021-05-26 23:24 ` Andre Przywara
2021-12-07 6:13 ` Jagan Teki
2021-05-19 19:42 ` [PATCH 5/6] dts: sunxi: v3s: enable emac support Andreas Rehn
2021-05-19 21:44 ` Andre Przywara
2021-05-19 19:42 ` [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout Andreas Rehn
2021-05-19 21:44 ` Andre Przywara
2021-05-19 22:10 ` Andreas Rehn
2021-05-19 22:46 ` Andre Przywara
2021-05-20 0:18 ` Andre Przywara
2021-05-21 20:14 ` Andreas Rehn [this message]
2021-06-03 13:56 ` Andre Przywara
2021-06-03 14:43 ` Heinrich Schuchardt
2021-06-03 15:29 ` Andreas Rehn
2021-05-22 23:23 ` [PATCH v2 " Andreas Rehn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPmT5DdF1v=BOR6SCMZvnqr3aE1yx94a1+904DeAfks2VbDXJg@mail.gmail.com' \
--to=rehn.andreas86@gmail.com \
--cc=andre.przywara@arm.com \
--cc=hdegoede@redhat.com \
--cc=icenowy@aosc.io \
--cc=jagan@amarulasolutions.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.