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

[Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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!

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