All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Thomas McKahan
	<tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Leonidas P. Papadakos"
	<papadakospan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v2] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay
Date: Sat, 09 Mar 2019 15:16:48 +0100	[thread overview]
Message-ID: <3966706.LBvcXR5hB6@phil> (raw)
In-Reply-To: <e9c539ce-f1cb-06f8-1083-ea64c9fd9e7b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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

  parent reply	other threads:[~2019-03-09 14:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 22:34 [PATCH v2] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay Leonidas P. Papadakos
     [not found] ` <20190306223454.2959-1-papadakospan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-06 22:37   ` Leonidas P. Papadakos
2019-03-08  1:05   ` Peter Geis
     [not found]     ` <24c5ffaa-644d-4623-a635-6842f67efe8a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-08  1:27       ` Leonidas P. Papadakos
     [not found]         ` <1552008447.3271.0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-08 23:26           ` Leonidas P. Papadakos
     [not found]             ` <1552087603.1401.0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09  2:39               ` Peter Geis
     [not found]                 ` <ec810aad-dd04-84e4-bfb0-98b005cf3f03-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09  3:26                   ` Leonidas P. Papadakos
     [not found]                     ` <1552101990.1401.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 12:45                       ` Peter Geis
     [not found]                         ` <e9c539ce-f1cb-06f8-1083-ea64c9fd9e7b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 14:16                           ` Heiko Stuebner [this message]
2019-03-09 14:21                             ` Peter Geis
     [not found]                               ` <4f17a798-ed28-8403-ed75-30fdf4bfc44b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 23:05                                 ` Leonidas P. Papadakos
     [not found]                                   ` <1552172735.1238.0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 23:16                                     ` Peter Geis
     [not found]                                       ` <1bab9d4c-5e9d-968d-026d-98e65af6e7ee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 23:25                                         ` Leonidas P. Papadakos
     [not found]                                           ` <1552173935.1238.1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-09 23:34                                             ` Peter Geis
     [not found]                                               ` <6d6a700a-39c9-25b6-dfff-296c0757603d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-10  0:26                                                 ` Leonidas P. Papadakos
2019-03-13 20:20                                                   ` Leonidas P. Papadakos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3966706.LBvcXR5hB6@phil \
    --to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=papadakospan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tonymckahan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.