On 11/24/2016 5:08 PM, Jerome Brunet wrote:
On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
cycle TX clock delay. This seems to work fine for many boards (for
example Odroid-C2 or Amlogic's reference boards) but there are some
others where TX traffic is simply broken.
There are probably multiple reasons why it's working on some boards
while it's broken on others:
- some of Amlogic's reference boards are using a Micrel PHY
- hardware circuit design
- maybe more...
This raises a question though:
Which device is supposed to enable the TX delay when both MAC and PHY
support it? And should we implement it for each PHY / MAC separately
or should we think about a more generic solution (currently it's not
possible to disable the TX delay generated by the RTL8211F PHY via
devicetree when using phy-mode "rgmii")?
iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
TX clock delay disabled on the MAC (as it's enabled in the PHY
driver).
TX throughput was virtually zero before:
$ iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port
5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 108 MBytes 901
Mbits/sec
[ 4] 1.00-2.00 sec 94.2 MBytes 791
Mbits/sec
[ 4] 2.00-3.00 sec 96.5 MBytes 810
Mbits/sec
[ 4] 3.00-4.00 sec 96.2 MBytes 808
Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 810
Mbits/sec
[ 4] 5.00-6.00 sec 96.5 MBytes 810
Mbits/sec
[ 4] 6.00-7.00 sec 96.6 MBytes 810
Mbits/sec
[ 4] 7.00-8.00 sec 96.5 MBytes 809
Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884
Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934
Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1000 MBytes 839
Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 998 MBytes 837
Mbits/sec receiver
iperf Done.
$ iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port
5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139
KBytes
[ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7
KBytes
[ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187
KBytes
[ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143
KBytes
[ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129
KBytes
[ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195
KBytes
[ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7
KBytes
[ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6
KBytes
[ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107
KBytes
[ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 1.02 GBytes 874
Mbits/sec 1189 sender
[ 4] 0.00-10.01 sec 1.02 GBytes 873
Mbits/sec receiver
Cool, one more board working ;)
I tried your patch on another board (MXQ_V2.1, with sheep printed on
the PCB). It 's not improving the situation for this one unfortunately.
Actually I already tried playing with the TX delay on the MAC and PHY
but I could get any good results with the boards I have.
It is strange that we can adjust the delay by 2ns steps, when delay
seens by the phy should be 2ns ...
Ok, as said, I could expect that extra delay was needed on GiGa.
FYI, on ST platforms, this extra delay was added in the pintctrl
dtsi. I mean, in some way, ad-hoc setup was solved at device-tree
level. Usually, extra delay could depend on the PCB.
peppe
iperf Done.
Martin Blumenstingl (2):
net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
Documentation/devicetree/bindings/net/meson-dwmac.txt | 11
+++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 16
+++++++++++-----
include/dt-bindings/net/dwmac-meson8b.h | 18
++++++++++++++++++
3 files changed, 40 insertions(+), 5 deletions(-)
create mode 100644 include/dt-bindings/net/dwmac-meson8b.h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
