Patchwork OMAP4430 SDP with KS8851: very slow networking

login
register
mail settings
Submitter Tony Lindgren
Date Dec. 6, 2018, 4:31 p.m.
Message ID <20181206163154.GK6707@atomide.com>
Download mbox | patch
Permalink /patch/674331/
State New
Headers show

Comments

Tony Lindgren - Dec. 6, 2018, 4:31 p.m.
Hi,

* Russell King - ARM Linux <linux@armlinux.org.uk> [181206 13:23]:
> It looks very much like a receive problem - in that the board is not
> always aware of a packet having been received until it attempts to
> transmit (eg, in the case of TFTP, when it re-sends the ACK after a
> receive timeout, it _then_ notices that there's a packet waiting.)
> 
> I'm not quite sure when this cropped up as I no longer regularly
> update and run my nightly boot tests, but I think 4.18 was fine.

Sounds like it's some gpio or PM related issue. If it's not caused
by commit b764a5863fd8 ("gpio: omap: Remove custom PM calls and
use cpu_pm instead"), then maybe the changes to probe devices
with ti-sysc interconnect target module driver caused it. Below
is a revert for mcspi that would help in that case.

Also I guess it could be caused by drivers/spi/spi-omap2-mcspi.c
changes since v4.18.

Care to post output of /sys/kernel/debug/pm_debug/count for
a working and non-working kernels?

Regards,

Tony

8< -------------------
Russell King - ARM Linux - Dec. 6, 2018, 6:08 p.m.
On Thu, Dec 06, 2018 at 08:31:54AM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Russell King - ARM Linux <linux@armlinux.org.uk> [181206 13:23]:
> > It looks very much like a receive problem - in that the board is not
> > always aware of a packet having been received until it attempts to
> > transmit (eg, in the case of TFTP, when it re-sends the ACK after a
> > receive timeout, it _then_ notices that there's a packet waiting.)
> > 
> > I'm not quite sure when this cropped up as I no longer regularly
> > update and run my nightly boot tests, but I think 4.18 was fine.
> 
> Sounds like it's some gpio or PM related issue. If it's not caused
> by commit b764a5863fd8 ("gpio: omap: Remove custom PM calls and
> use cpu_pm instead"), then maybe the changes to probe devices
> with ti-sysc interconnect target module driver caused it. Below
> is a revert for mcspi that would help in that case.

In the interests of keeping the mailing list record up to date, with
the following:

850d434ea37b ("gpio: omap: Remove set but not used variable 'dev'")
c4791bc6e3a6 ("gpio: omap: drop omap_gpio_list")
467480738d0b ("gpio: omap: get rid of the conditional PM runtime calls")
5284521a290e ("gpio: omap: Get rid of pm_runtime_irq_safe()")
b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")

reverted, the problem is still there.  Revert:

ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4 based SoCs")

on top, and networking returns to normal.  So it appears to be this
last commit causing the issue.

With that and b764a5863fd8 applied, it still misbehaves.  Then, poking
at the OMAP4_GPIO_IRQWAKEN0 register, changing it from 0 to 4 with
devmem2 restores normal behaviour - ping times are normal and NFS is
happy.

# devmem2 0x48055044 w 4

(slightly more complex for me as its via NFS and needs different C
libraries from the ones on the rootfs.)

Given that this GPIO device is not runtime suspended, and is
permanently active (which is what I think we expect, given that it
has an IRQ claimed against it) does the hardware still attempt to
idle the GPIO block - if so, could that be why we need to program
the wakeup register, so the GPIO block signals that it's active?
Tony Lindgren - Dec. 6, 2018, 10:14 p.m.
* Russell King - ARM Linux <linux@armlinux.org.uk> [181206 18:08]:
> reverted, the problem is still there.  Revert:
> 
> ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4 based SoCs")
> 
> on top, and networking returns to normal.  So it appears to be this
> last commit causing the issue.
> 
> With that and b764a5863fd8 applied, it still misbehaves.  Then, poking
> at the OMAP4_GPIO_IRQWAKEN0 register, changing it from 0 to 4 with
> devmem2 restores normal behaviour - ping times are normal and NFS is
> happy.
> 
> # devmem2 0x48055044 w 4

OK thanks.

> Given that this GPIO device is not runtime suspended, and is
> permanently active (which is what I think we expect, given that it
> has an IRQ claimed against it) does the hardware still attempt to
> idle the GPIO block - if so, could that be why we need to program
> the wakeup register, so the GPIO block signals that it's active?

Yes we now idle non-irq GPIOs only from CPU_CLUSTER_PM_ENTER
as the selected cpuidle state triggers the domain transitions
with WFI. And that's why runtime_suspended_time does not increase
for a GPIO instance with IRQs.

I can reproduce the long ping latencies on duovero smsc connected
to gpio_44, I'll try to debug it more.

Regards,

Tony

Patch

diff --git a/arch/arm/boot/dts/omap4-l4.dtsi b/arch/arm/boot/dts/omap4-l4.dtsi
--- a/arch/arm/boot/dts/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/omap4-l4.dtsi
@@ -2050,25 +2050,7 @@ 
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0x0 0x98000 0x1000>;
-
-			mcspi1: spi@0 {
-				compatible = "ti,omap4-mcspi";
-				reg = <0x0 0x200>;
-				interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				ti,spi-num-cs = <4>;
-				dmas = <&sdma 35>,
-				       <&sdma 36>,
-				       <&sdma 37>,
-				       <&sdma 38>,
-				       <&sdma 39>,
-				       <&sdma 40>,
-				       <&sdma 41>,
-				       <&sdma 42>;
-				dma-names = "tx0", "rx0", "tx1", "rx1",
-					    "tx2", "rx2", "tx3", "rx3";
-			};
+			status = "disabled";
 		};
 
 		target-module@9a000 {			/* 0x4809a000, ap 51 2c.0 */
@@ -2089,20 +2071,7 @@ 
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0x0 0x9a000 0x1000>;
-
-			mcspi2: spi@0 {
-				compatible = "ti,omap4-mcspi";
-				reg = <0x0 0x200>;
-				interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				ti,spi-num-cs = <2>;
-				dmas = <&sdma 43>,
-				       <&sdma 44>,
-				       <&sdma 45>,
-				       <&sdma 46>;
-				dma-names = "tx0", "rx0", "tx1", "rx1";
-			};
+			status = "disabled";
 		};
 
 		target-module@9c000 {			/* 0x4809c000, ap 53 36.0 */
@@ -2290,17 +2259,7 @@ 
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0x0 0xb8000 0x1000>;
-
-			mcspi3: spi@0 {
-				compatible = "ti,omap4-mcspi";
-				reg = <0x0 0x200>;
-				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				ti,spi-num-cs = <2>;
-				dmas = <&sdma 15>, <&sdma 16>;
-				dma-names = "tx0", "rx0";
-			};
+			status = "disabled";
 		};
 
 		target-module@ba000 {			/* 0x480ba000, ap 71 32.0 */
@@ -2321,17 +2280,7 @@ 
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0x0 0xba000 0x1000>;
-
-			mcspi4: spi@0 {
-				compatible = "ti,omap4-mcspi";
-				reg = <0x0 0x200>;
-				interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				ti,spi-num-cs = <1>;
-				dmas = <&sdma 70>, <&sdma 71>;
-				dma-names = "tx0", "rx0";
-			};
+			status = "disabled";
 		};
 
 		target-module@d1000 {			/* 0x480d1000, ap 73 44.0 */
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -193,6 +193,66 @@ 
 			#gpio-cells = <2>;
 		};
 
+		mcspi1: spi@48098000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x48098000 0x200>;
+			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi1";
+			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: spi@4809a000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x4809a000 0x200>;
+			interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi2";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		mcspi3: spi@480b8000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480b8000 0x200>;
+			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi3";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
+		};
+
+		mcspi4: spi@480ba000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480ba000 0x200>;
+			interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi4";
+			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
+		};
+
+
 		mmu_dsp: mmu@4a066000 {
 			compatible = "ti,omap4-iommu";
 			reg = <0x4a066000 0x100>;