Re: [PATCH v2] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay

["Leonidas P. Papadakos" <papadakospan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Στις Σαβ, 9 Μαρ, 2019 at 4:21 ΜΜ, ο/η Peter Geis 
<pgwipeout@gmail.com> έγραψε:
> 
> 
> On 3/9/2019 9:16 AM, Heiko Stuebner wrote:
>> Am Samstag, 9. März 2019, 13:45:21 CET schrieb Peter Geis:
>>> On 3/8/2019 10:26 PM, Leonidas P. Papadakos wrote:
>>>> 
>>>>> So I discovered the cause of my TX issues, at least on my 
>>>>> rk3328-roc-cc.
>>>>> The rk3328.dtsi is missing several rgmii tx pull strength values.
>>>>> This is causing them to default to 0ma.
>>>>> 
>>>>> I've pushed them to 12ma, same as the other tx values, and I'm 
>>>>> getting
>>>>> 600 mbps tx, with no TX failures.
>>>>> 
>>>>> I am also going to test his adaptive patch once it's done 
>>>>> building.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> 
>>>>> diff --git a/arch/arm65/boot/dts/rockchip/rk3328-roc-cc.dts
>>>>> b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>>> index c0519bc5884e..696627bf3331 100644
>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>>> @@ -280,6 +280,26 @@
>>>>>               rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO 
>>>>> &pcfg_pull_none>;
>>>>>           };
>>>>>       };
>>>>> +
>>>>> +    gmac-1 {
>>>>> +        rgmiim1_pins: rgmiim1-pins {
>>>>> +            rockchip,pins =
>>>>> +                /* mac_txclk */
>>>>> +                <0 RK_PB0 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_txen */
>>>>> +                <0 RK_PB4 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_clk */
>>>>> +                <0 RK_PD0 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_txd1 */
>>>>> +                <0 RK_PC0 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_txd0 */
>>>>> +                <0 RK_PC1 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_txd3 */
>>>>> +                <0 RK_PC7 1 &pcfg_pull_none_12ma>,
>>>>> +                /* mac_txd2 */
>>>>> +                <0 RK_PC6 1 &pcfg_pull_none_12ma>;
>>>>> +        };
>>>>> +    };
>>>>>   };
>>>>> 
>>>>>   &sdmmc {
>>>> Good find! It seems like they're there in the dtsi, but configured 
>>>> as
>>>> none when it comes to ma. I'll test it
>>>> 
>>>> 
>>> 
>>> With Ayufan's patch offload patch and my pull patch, I now have the
>>> following results:
>>> [ ID] Interval           Transfer     Bitrate         Retr
>>> [  5]   0.00-10.01  sec  1022 MBytes   857 Mbits/sec  885           
>>>   sender
>>> [  5]   0.00-10.01  sec  1022 MBytes   856 Mbits/sec
>>> receiver
>>> 
>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>>           inet6 fe80::e8b5:5eff:fe49:d353  prefixlen 64  scopeid 
>>> 0x20<link>
>>>           ether ea:b5:5e:49:d3:53  txqueuelen 1000  (Ethernet)
>>>           RX packets 39822  bytes 2668618 (2.6 MB)
>>>           RX errors 0  dropped 0  overruns 0  frame 0
>>>           TX packets 1005649  bytes 1516698158 (1.5 GB)
>>>           TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>>           device interrupt 29
>>> 
>>> Much better overall, still not perfect, but I think it might be 
>>> worth
>>> re-running the delay tests now.
>> 
>> also you could check if the thres-dma-flag is still necessary or can
>> be removed - might be interesting to know if fixing the drive 
>> strength
>> magically also fixes that issue.
>> 
>> 
>> Heiko
>> 
> 
> Part of my test was removing that flag.
> I actually haven't run with it for a while, since I chose to disable 
> offload in userspace instead.
> With threshold DMA I was having serious performance issues, but it 
> was better than networking being completely broken.
> 
> I'll write up a patch for the .dtsi and submit it today.
> If we can contact ayufan about his patch, that would be great!

For the test I use iperf3 -s on my laptop (Gigabit Ethernet)
and on the renegade: iperf3 -c <laptop_ip> -t 30.

I tried using:
1) the force-thresh-dma-mode patch by itself with the changed 
tx/rx_delay. (Maybe the default one is better? It needs testing nayway)
   No ssh lag but I do get the Link reset on tx activity

2) just this patch by itself
   the ssh lag hit me, but it does seem better. The link reset still 
happens

3) the force-thresh-dma-mode patch with this one:
   No shs lag, and as before, the tx activity seems to hit less? (Maybe 
placebo) but the link reset does happen regularly.

As far as I understand ayufan's offload patch removes the need for the 
force-thresh-dma-mode flag.
I'll try ayufan's patch (adding the option to the rk3328-roc-cc as 
well) together with this patch.
Maybe it'll be better



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip