netdev - Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1480003681.17538.142.camel@baylibre.com>
Date:   Thu, 24 Nov 2016 17:08:01 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-amlogic@...ts.infradead.org, devicetree@...r.kernel.org,
        netdev@...r.kernel.org, davem@...emloft.net, khilman@...libre.com,
        mark.rutland@....com, robh+dt@...nel.org
Cc:     linux-arm-kernel@...ts.infradead.org, alexandre.torgue@...com,
        peppe.cavallaro@...com, carlo@...one.org
Subject: Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable
 RGMII TX delay

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 ...

> 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
>