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: <d14f43e6-73f7-665f-28f4-cbe6e762cab0@st.com>
Date:   Fri, 25 Nov 2016 09:59:33 +0100
From:   Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        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>,
        <carlo@...one.org>
Subject: Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII
 TX delay

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