| Message ID | 20190607123731.8737-1-pgwipeout@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: rockchip: improve rk3328-roc-cc rgmii performance. | expand |
I'll test on my board, but if in the end it does end up being a change to both tx and rxpbl then we can replce the 2 tx/rxpbl options with one, as far as I know: snps,pbl = <0x4>;
On Fri, Jun 7, 2019 at 8:58 AM Leonidas P. Papadakos <papadakospan@gmail.com> wrote: > > > I'll test on my board, but if in the end it does end up being a change > to both tx and rxpbl then we can replce the 2 tx/rxpbl options with > one, as far as I know: > > snps,pbl = <0x4>; > > The big change was actually snps,aal. As per the TRM, DMA channels not address aligned have severe limitations, if they work at all. Setting the DMA ops as address aligned fixed my 30mbps TX issue when combined with your snps,txpbl = <0x4>.
Am Samstag, 8. Juni 2019, 01:07:48 CEST schrieb Peter Geis: > On Fri, Jun 7, 2019 at 8:58 AM Leonidas P. Papadakos > <papadakospan@gmail.com> wrote: > > > > > > I'll test on my board, but if in the end it does end up being a change > > to both tx and rxpbl then we can replce the 2 tx/rxpbl options with > > one, as far as I know: > > > > snps,pbl = <0x4>; > > > > > > The big change was actually snps,aal. > As per the TRM, DMA channels not address aligned have severe > limitations, if they work at all. > > Setting the DMA ops as address aligned fixed my 30mbps TX issue when > combined with your snps,txpbl = <0x4>. same as with the other patch: I've lost track of what matters, so please resend the ones that matter with appropriate Tested-by, Reviewed-by tags by involved people. Thanks Heiko
> > same as with the other patch: I've lost track of what matters, > so please resend the ones that matter with appropriate > Tested-by, Reviewed-by tags by involved people. > > Thanks > Heiko > > Understandable, really. haha! The conversation is ongoing. I'll test this now that that loaded week has passed and see if we can reach something better than dropping tx offload. This might be it, if it works for more than one device
> The big change was actually snps,aal. > As per the TRM, DMA channels not address aligned have severe > limitations, if they work at all. > > Setting the DMA ops as address aligned fixed my 30mbps TX issue when > combined with your snps,txpbl = <0x4>. Honestly, I don't notice any difference either way with aal. So what happens without it? If You only use the 0x4 txpbl and having removed thresh dma mode, (2 things then) do you get bad tx?
On 6/14/2019 5:27 PM, Leonidas P. Papadakos wrote: > > >> The big change was actually snps,aal. >> As per the TRM, DMA channels not address aligned have severe >> limitations, if they work at all. >> >> Setting the DMA ops as address aligned fixed my 30mbps TX issue when >> combined with your snps,txpbl = <0x4>. > > Honestly, I don't notice any difference either way with aal. So what > happens without it? If You only use the 0x4 txpbl and having removed > thresh dma mode, (2 things then) do you get bad tx? > > I'm unsure why, but I think there might be small variations in the different boards (Firefly, Libre). On my board (Libre) with just 0x4 txpbl and thresh dma removed I get a whopping 30mbps. Adding aal brought it up to 900 mbps. I also had stability issues on rx, where it would bounce between 200 and 400 mbps, which adding 0x4 rxpbl helped. I still haven't been able to get rx above 400mpbs though. It's definitely the MTU issue, since setting the max mtu to 1496 fixes most problems. I have to wonder if the pl330 in the rk3328 is bugged, since all of the hardware that misbehaves (usb3, mmc, rgmii) require the dma engine. If this works as a valid replacement for thresh dma mode, then I can submit it for merging. I would like a few more people to test it first. Anyone else with a rk3328-roc-cc board that can test this patch?
On 2019-06-15 14:12, Peter Geis wrote: > > On 6/14/2019 5:27 PM, Leonidas P. Papadakos wrote: >> >>> The big change was actually snps,aal. >>> As per the TRM, DMA channels not address aligned have severe >>> limitations, if they work at all. >>> >>> Setting the DMA ops as address aligned fixed my 30mbps TX issue when >>> combined with your snps,txpbl = <0x4>. >> Honestly, I don't notice any difference either way with aal. So what >> happens without it? If You only use the 0x4 txpbl and having removed >> thresh dma mode, (2 things then) do you get bad tx? >> >> > I'm unsure why, but I think there might be small variations in the > different boards (Firefly, Libre). > On my board (Libre) with just 0x4 txpbl and thresh dma removed I get a > whopping 30mbps. > > Adding aal brought it up to 900 mbps. > > I also had stability issues on rx, where it would bounce between 200 and > 400 mbps, which adding 0x4 rxpbl helped. > I still haven't been able to get rx above 400mpbs though. > > It's definitely the MTU issue, since setting the max mtu to 1496 fixes > most problems. > > I have to wonder if the pl330 in the rk3328 is bugged, since all of the > hardware that misbehaves (usb3, mmc, rgmii) require the dma engine. > > If this works as a valid replacement for thresh dma mode, then I can > submit it for merging. > I would like a few more people to test it first. > > Anyone else with a rk3328-roc-cc board that can test this patch? > I will try to run some tests using this patch on my different rk3328 devices tomorrow. One thing I have noticed is that when vdd_logic is less then 1.05v the network connection gets super slow. Earlier I tried to use devfreq and an opp table for gpu, but that caused vdd_logic to use lower voltage. I have since then run gpu driver without devfreq/opp table and vdd_logic is using default 1.1v. My board seems much more stable using default 1.1v for vdd_logic. Regards, Jonas
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts index 5d499c9086fb..8bcc08de82fb 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts @@ -141,10 +141,12 @@ phy-mode = "rgmii"; pinctrl-names = "default"; pinctrl-0 = <&rgmiim1_pins>; - snps,force_thresh_dma_mode; snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; snps,reset-active-low; snps,reset-delays-us = <0 10000 50000>; + snps,txpbl = <0x4>; + snps,rxpbl = <0x4>; + snps,aal; tx_delay = <0x24>; rx_delay = <0x18>; status = "okay";
Currently the rk3328-roc-cc ethernet is enabled using "snps,force_thresh_dma_mode". While this works, the performance leaves a lot to be desired. A previous attempt to improve performance used "snps,txpbl = <0x4>". This also allowed networking to function, but performance varied between boards. This patch takes that one step further. Set txpbl and rxpbl to 0x4. This can also be accomplished with "snps,pbl =<0x4>" which affects both. Also set "snps,aal" which forces address aligned DMA mode. On my board this achieves the best performance yet, however we need broad testing to ensure this works for everyone. Please test and provide feedback. Signed-off-by: Peter Geis <pgwipeout@gmail.com> --- arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)