Patchwork [net-next] r8169: Remove rtl_ocpdr_cond

login
register
mail settings
Submitter hayeswang
Date July 11, 2012, 12:31 p.m.
Message ID <1342009916-1519-1-git-send-email-hayeswang@realtek.com>
Download mbox | patch
Permalink /patch/170459/
State Deferred
Delegated to: David Miller
Headers show

Comments

hayeswang - July 11, 2012, 12:31 p.m.
No waiting is needed for mac_ocp_{write / read}. And the bit 31 of
OCPDR would not change, so rtl_udelay_loop_wait_high always return
false. That is, the r8168_mac_ocp_read always retuen ~0.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
 drivers/net/ethernet/realtek/r8169.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)
françois romieu - July 11, 2012, 10 p.m.
Hayes Wang <hayeswang@realtek.com> :
> No waiting is needed for mac_ocp_{write / read}. And the bit 31 of
> OCPDR would not change, so rtl_udelay_loop_wait_high always return
> false. That is, the r8168_mac_ocp_read always retuen ~0.

(testing with davem's 48ee3569f31d91084dc694fef5517eb782428083)

It seemed right at first sight but testing without firmware produces
unexpected results. While it is not exactly fast if I ask it to emit
packets with ping -qf, it turns really slow when I use the -l preload
option: at most a few hundreds pps.

An old pcie 8168b in the same computer behaves correctly with the same
kernel.

I'll try again tomorrow evening.
françois romieu - July 12, 2012, 10:14 p.m.
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> I'll try again tomorrow evening.

W/o firmware does not seem to make a difference.

# ping -qf -l 4 -s 81 -c 60 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data.

--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 153ms
rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, ipg/ewma 2.607/0.058 ms

# ping -qf -l 4 -s 82 -c 60 10.0.3.1                                                     
PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data.

--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, ipg/ewma 0.057/0.205 ms

It would translate into a 127/128 cutoff after inclusion of the FCS.

Any idea ?
hayeswang - July 13, 2012, 3:17 a.m.
Francois Romieu [mailto:romieu@fr.zoreil.com] 
[...]
> 
> W/o firmware does not seem to make a difference.
> 
> # ping -qf -l 4 -s 81 -c 60 10.0.3.1
> PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data.
> 
> --- 10.0.3.1 ping statistics ---
> 60 packets transmitted, 60 received, 0% packet loss, time 153ms
> rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, 
> ipg/ewma 2.607/0.058 ms

# ping -qf -l 4 -s 81 -c 60 192.168.94.20
PING 192.168.94.20 (192.168.94.20) 81(109) bytes of data.

--- 192.168.94.20 ping statistics ---
60 packets transmitted, 57 received, 5% packet loss, time 1ms
rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035
ms

> # ping -qf -l 4 -s 82 -c 60 10.0.3.1                          
>                            
> PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data.
> 
> --- 10.0.3.1 ping statistics ---
> 60 packets transmitted, 60 received, 0% packet loss, time 3ms
> rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, 
> ipg/ewma 0.057/0.205 ms

# ping -qf -l 4 -s 82 -c 60 192.168.94.20
PING 192.168.94.20 (192.168.94.20) 82(110) bytes of data.

--- 192.168.94.20 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168
ms

> It would translate into a 127/128 cutoff after inclusion of the FCS.
> 
> Any idea ?
> 

The attatched file is my log. It seems fine.
françois romieu - July 17, 2012, 10:10 a.m.
hayeswang <hayeswang@realtek.com> :
[...]
> rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035
> rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168
[...]
> The attached file is my log. It seems fine.

A few percents packet loss at this rate does not exactly qualify as fine.

I have reproduced something similar with a 8168evl in a different slot so
it does not seem to be a 8168g only behavior. I'll ask davem to pull your
changes.

Thanks.

Patch

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index c29c5fb..1f27318 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1043,13 +1043,6 @@  static void rtl_w1w0_phy_ocp(struct rtl8169_private *tp, int reg, int p, int m)
 	r8168_phy_ocp_write(tp, reg, (val | p) & ~m);
 }
 
-DECLARE_RTL_COND(rtl_ocpdr_cond)
-{
-	void __iomem *ioaddr = tp->mmio_addr;
-
-	return RTL_R32(OCPDR) & OCPAR_FLAG;
-}
-
 static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
 {
 	void __iomem *ioaddr = tp->mmio_addr;
@@ -1058,8 +1051,6 @@  static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
 		return;
 
 	RTL_W32(OCPDR, OCPAR_FLAG | (reg << 15) | data);
-
-	rtl_udelay_loop_wait_low(tp, &rtl_ocpdr_cond, 25, 10);
 }
 
 static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg)
@@ -1071,8 +1062,7 @@  static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg)
 
 	RTL_W32(OCPDR, reg << 15);
 
-	return rtl_udelay_loop_wait_high(tp, &rtl_ocpdr_cond, 25, 10) ?
-		RTL_R32(OCPDR) : ~0;
+	return RTL_R32(OCPDR);
 }
 
 #define OCP_STD_PHY_BASE	0xa400