From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: linux-amlogic@lists.infradead.org, netdev@vger.kernel.org,
davem@davemloft.net, khilman@baylibre.com
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, balbes-150@yandex.ru,
ingrassia@epigenesys.com, jbrunet@baylibre.com,
linus.luessing@c0d3.blue,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: [PATCH 0/3] Meson8b/8m2: Ethernet RGMII TX delay fixes
Date: Wed, 25 Dec 2019 01:56:52 +0100 [thread overview]
Message-ID: <20191225005655.1502037-1-martin.blumenstingl@googlemail.com> (raw)
The Ethernet TX performance has been historically bad on Meson8b and
Meson8m2 SoCs because high packet loss was seen. Today I (presumably)
found out why this is: the input clock (which feeds the RGMII TX clock)
has to be at least 4 times 125MHz. With the fixed "divide by 2" in the
clock tree this means that m250_div needs to be at least 2.
Now the PRG_ETH0 register in Linux matches what u-boot and the vendor
3.10 kernel use. iperf3 output on my Odroid-C1 (where this series has
been tested):
# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.163 port 42636 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 105 MBytes 878 Mbits/sec 0 609 KBytes
[ 5] 1.00-2.00 sec 106 MBytes 885 Mbits/sec 0 683 KBytes
[ 5] 2.00-3.09 sec 73.7 MBytes 570 Mbits/sec 0 683 KBytes
[ 5] 3.09-4.00 sec 81.9 MBytes 754 Mbits/sec 0 795 KBytes
[ 5] 4.00-5.00 sec 104 MBytes 869 Mbits/sec 0 877 KBytes
[ 5] 5.00-6.00 sec 105 MBytes 878 Mbits/sec 0 877 KBytes
[ 5] 6.00-7.00 sec 68.0 MBytes 571 Mbits/sec 0 877 KBytes
[ 5] 7.00-8.00 sec 80.7 MBytes 676 Mbits/sec 0 877 KBytes
[ 5] 8.00-9.01 sec 102 MBytes 853 Mbits/sec 0 877 KBytes
[ 5] 9.01-10.00 sec 101 MBytes 859 Mbits/sec 0 877 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 927 MBytes 778 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 927 MBytes 777 Mbits/sec receiver
@David: please only apply patch #1 from this series. I included the .dts
changes so others can test them together with the driver update (as the
.dts has to be updated to fully fix the TX packet loss - with the old TX
delay in the .dts there is still packet loss, even with a fixed driver).
I will ask Kevin to apply patches #2 and #3 through his linux-amlogic
tree - or resend them. When applying the .dts patches without the fix in
the driver then I get 100% packet loss on my Odroid-C1. So unfortunately
there's a hard dependency between patch 1 and 2/3.
Martin Blumenstingl (3):
net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs
ARM: dts: meson8b: odroidc1: use the same RGMII TX delay as u-boot
ARM: dts: meson8m2: mxiii-plus: use the same RGMII TX delay as u-boot
arch/arm/boot/dts/meson8b-odroidc1.dts | 2 +-
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 2 +-
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 14 +++++++++++---
3 files changed, 13 insertions(+), 5 deletions(-)
--
2.24.1
WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: linux-amlogic@lists.infradead.org, netdev@vger.kernel.org,
davem@davemloft.net, khilman@baylibre.com
Cc: linus.luessing@c0d3.blue, balbes-150@yandex.ru,
linux-kernel@vger.kernel.org,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-arm-kernel@lists.infradead.org, ingrassia@epigenesys.com,
jbrunet@baylibre.com
Subject: [PATCH 0/3] Meson8b/8m2: Ethernet RGMII TX delay fixes
Date: Wed, 25 Dec 2019 01:56:52 +0100 [thread overview]
Message-ID: <20191225005655.1502037-1-martin.blumenstingl@googlemail.com> (raw)
The Ethernet TX performance has been historically bad on Meson8b and
Meson8m2 SoCs because high packet loss was seen. Today I (presumably)
found out why this is: the input clock (which feeds the RGMII TX clock)
has to be at least 4 times 125MHz. With the fixed "divide by 2" in the
clock tree this means that m250_div needs to be at least 2.
Now the PRG_ETH0 register in Linux matches what u-boot and the vendor
3.10 kernel use. iperf3 output on my Odroid-C1 (where this series has
been tested):
# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.163 port 42636 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 105 MBytes 878 Mbits/sec 0 609 KBytes
[ 5] 1.00-2.00 sec 106 MBytes 885 Mbits/sec 0 683 KBytes
[ 5] 2.00-3.09 sec 73.7 MBytes 570 Mbits/sec 0 683 KBytes
[ 5] 3.09-4.00 sec 81.9 MBytes 754 Mbits/sec 0 795 KBytes
[ 5] 4.00-5.00 sec 104 MBytes 869 Mbits/sec 0 877 KBytes
[ 5] 5.00-6.00 sec 105 MBytes 878 Mbits/sec 0 877 KBytes
[ 5] 6.00-7.00 sec 68.0 MBytes 571 Mbits/sec 0 877 KBytes
[ 5] 7.00-8.00 sec 80.7 MBytes 676 Mbits/sec 0 877 KBytes
[ 5] 8.00-9.01 sec 102 MBytes 853 Mbits/sec 0 877 KBytes
[ 5] 9.01-10.00 sec 101 MBytes 859 Mbits/sec 0 877 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 927 MBytes 778 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 927 MBytes 777 Mbits/sec receiver
@David: please only apply patch #1 from this series. I included the .dts
changes so others can test them together with the driver update (as the
.dts has to be updated to fully fix the TX packet loss - with the old TX
delay in the .dts there is still packet loss, even with a fixed driver).
I will ask Kevin to apply patches #2 and #3 through his linux-amlogic
tree - or resend them. When applying the .dts patches without the fix in
the driver then I get 100% packet loss on my Odroid-C1. So unfortunately
there's a hard dependency between patch 1 and 2/3.
Martin Blumenstingl (3):
net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs
ARM: dts: meson8b: odroidc1: use the same RGMII TX delay as u-boot
ARM: dts: meson8m2: mxiii-plus: use the same RGMII TX delay as u-boot
arch/arm/boot/dts/meson8b-odroidc1.dts | 2 +-
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 2 +-
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 14 +++++++++++---
3 files changed, 13 insertions(+), 5 deletions(-)
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: linux-amlogic@lists.infradead.org, netdev@vger.kernel.org,
davem@davemloft.net, khilman@baylibre.com
Cc: linus.luessing@c0d3.blue, balbes-150@yandex.ru,
linux-kernel@vger.kernel.org,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-arm-kernel@lists.infradead.org, ingrassia@epigenesys.com,
jbrunet@baylibre.com
Subject: [PATCH 0/3] Meson8b/8m2: Ethernet RGMII TX delay fixes
Date: Wed, 25 Dec 2019 01:56:52 +0100 [thread overview]
Message-ID: <20191225005655.1502037-1-martin.blumenstingl@googlemail.com> (raw)
The Ethernet TX performance has been historically bad on Meson8b and
Meson8m2 SoCs because high packet loss was seen. Today I (presumably)
found out why this is: the input clock (which feeds the RGMII TX clock)
has to be at least 4 times 125MHz. With the fixed "divide by 2" in the
clock tree this means that m250_div needs to be at least 2.
Now the PRG_ETH0 register in Linux matches what u-boot and the vendor
3.10 kernel use. iperf3 output on my Odroid-C1 (where this series has
been tested):
# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.163 port 42636 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 105 MBytes 878 Mbits/sec 0 609 KBytes
[ 5] 1.00-2.00 sec 106 MBytes 885 Mbits/sec 0 683 KBytes
[ 5] 2.00-3.09 sec 73.7 MBytes 570 Mbits/sec 0 683 KBytes
[ 5] 3.09-4.00 sec 81.9 MBytes 754 Mbits/sec 0 795 KBytes
[ 5] 4.00-5.00 sec 104 MBytes 869 Mbits/sec 0 877 KBytes
[ 5] 5.00-6.00 sec 105 MBytes 878 Mbits/sec 0 877 KBytes
[ 5] 6.00-7.00 sec 68.0 MBytes 571 Mbits/sec 0 877 KBytes
[ 5] 7.00-8.00 sec 80.7 MBytes 676 Mbits/sec 0 877 KBytes
[ 5] 8.00-9.01 sec 102 MBytes 853 Mbits/sec 0 877 KBytes
[ 5] 9.01-10.00 sec 101 MBytes 859 Mbits/sec 0 877 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 927 MBytes 778 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 927 MBytes 777 Mbits/sec receiver
@David: please only apply patch #1 from this series. I included the .dts
changes so others can test them together with the driver update (as the
.dts has to be updated to fully fix the TX packet loss - with the old TX
delay in the .dts there is still packet loss, even with a fixed driver).
I will ask Kevin to apply patches #2 and #3 through his linux-amlogic
tree - or resend them. When applying the .dts patches without the fix in
the driver then I get 100% packet loss on my Odroid-C1. So unfortunately
there's a hard dependency between patch 1 and 2/3.
Martin Blumenstingl (3):
net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs
ARM: dts: meson8b: odroidc1: use the same RGMII TX delay as u-boot
ARM: dts: meson8m2: mxiii-plus: use the same RGMII TX delay as u-boot
arch/arm/boot/dts/meson8b-odroidc1.dts | 2 +-
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 2 +-
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 14 +++++++++++---
3 files changed, 13 insertions(+), 5 deletions(-)
--
2.24.1
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next reply other threads:[~2019-12-25 0:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 0:56 Martin Blumenstingl [this message]
2019-12-25 0:56 ` [PATCH 0/3] Meson8b/8m2: Ethernet RGMII TX delay fixes Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 0:56 ` [PATCH 1/3] net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 15:08 ` Andrew Lunn
2019-12-25 15:08 ` Andrew Lunn
2019-12-25 15:08 ` Andrew Lunn
2019-12-25 15:33 ` Martin Blumenstingl
2019-12-25 15:33 ` Martin Blumenstingl
2019-12-25 15:33 ` Martin Blumenstingl
2019-12-26 10:50 ` Andrew Lunn
2019-12-26 10:50 ` Andrew Lunn
2019-12-26 10:50 ` Andrew Lunn
2019-12-26 11:39 ` Martin Blumenstingl
2019-12-26 11:39 ` Martin Blumenstingl
2019-12-26 11:39 ` Martin Blumenstingl
2019-12-26 12:01 ` Andrew Lunn
2019-12-26 12:01 ` Andrew Lunn
2019-12-26 12:01 ` Andrew Lunn
2019-12-26 18:17 ` Martin Blumenstingl
2019-12-26 18:17 ` Martin Blumenstingl
2019-12-26 18:17 ` Martin Blumenstingl
2019-12-25 0:56 ` [PATCH 2/3] ARM: dts: meson8b: odroidc1: use the same RGMII TX delay as u-boot Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 0:56 ` [PATCH 3/3] ARM: dts: meson8m2: mxiii-plus: " Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-25 0:56 ` Martin Blumenstingl
2019-12-28 0:33 ` [PATCH 0/3] Meson8b/8m2: Ethernet RGMII TX delay fixes David Miller
2019-12-28 0:33 ` David Miller
2019-12-28 0:33 ` David Miller
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=20191225005655.1502037-1-martin.blumenstingl@googlemail.com \
--to=martin.blumenstingl@googlemail.com \
--cc=balbes-150@yandex.ru \
--cc=davem@davemloft.net \
--cc=ingrassia@epigenesys.com \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=linus.luessing@c0d3.blue \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.