On Thu, Aug 7, 2014 at 11:20 AM, Fabio Estevam <feste...@gmail.com> wrote:
> On a imx6q sabreauto I also get:
>
> 151: 0 0 0 0 GIC 151
> 2188000.ethernet
> 166: 4577 0 0 0 gpio-mxc 6
> 2188000.ethernet
>
> and the GPIO1_6 interrupt comes from this commit:
>
> commit bc20a5d6da718f9d60da0a78f70c653c1cd16af3
> Author: Troy Kisky <troy.ki...@boundarydevices.com>
> Date: Fri Dec 20 11:47:12 2013 -0700
>
> ARM: dts: imx6qdl-sabreauto: use GPIO_6 for FEC interrupt.
>
> This works around a hardware bug.
>
> Signed-off-by: Troy Kisky <troy.ki...@boundarydevices.com>
> Signed-off-by: Shawn Guo <shawn....@linaro.org>
Actually a more descriptive commit log can be found here:
commit 6261c4c8f13eb91f733e8ba6d67c409a2e841667
Author: Troy Kisky <troy.ki...@boundarydevices.com>
Date: Fri Dec 20 11:47:11 2013 -0700
ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt.
This works around a hardware bug.
From "Chip Errata for the i.MX 6Dual/6Quad"
ERR006687 ENET: Only the ENET wake-up interrupt request can wake the
system from Wait mode.
The ENET block generates many interrupts. Only one of these interrupt lines
is connected to the General Power Controller (GPC) block, but a logical OR
of all of the ENET interrupts is connected to the General
Interrupt Controller
(GIC). When the system enters Wait mode, a normal RX Done or TX
Done does not
wake up the system because the GPC cannot see this interrupt. This impacts
performance of the ENET block because its interrupts are serviced only when
the chip exits Wait mode due to an interrupt from some other wake-up source.
Before this patch, ping times of a Sabre Lite board are quite
random:
ping 192.168.0.13 -i.5 -c5
PING 192.168.0.13 (192.168.0.13) 56(84) bytes of data.
64 bytes from 192.168.0.13: icmp_req=1 ttl=64 time=15.7 ms
64 bytes from 192.168.0.13: icmp_req=2 ttl=64 time=14.4 ms
64 bytes from 192.168.0.13: icmp_req=3 ttl=64 time=13.4 ms
64 bytes from 192.168.0.13: icmp_req=4 ttl=64 time=12.4 ms
64 bytes from 192.168.0.13: icmp_req=5 ttl=64 time=11.4 ms
=== 192.168.0.13 ping statistics ===
5 packets transmitted, 5 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 11.431/13.501/15.746/1.508 ms
____________________________________________________
After this patch:
ping 192.168.0.13 -i.5 -c5
PING 192.168.0.13 (192.168.0.13) 56(84) bytes of data.
64 bytes from 192.168.0.13: icmp_req=1 ttl=64 time=0.120 ms
64 bytes from 192.168.0.13: icmp_req=2 ttl=64 time=0.175 ms
64 bytes from 192.168.0.13: icmp_req=3 ttl=64 time=0.169 ms
64 bytes from 192.168.0.13: icmp_req=4 ttl=64 time=0.168 ms
64 bytes from 192.168.0.13: icmp_req=5 ttl=64 time=0.172 ms
=== 192.168.0.13 ping statistics ===
5 packets transmitted, 5 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.120/0.160/0.175/0.026 ms
____________________________________________________
Also, apply same change to imx6qdl-nitrogen6x.
This change may not be appropriate for all boards.
Sabre Lite uses GPIO6 as a power down output for a ov5642
camera. As this expansion board does not yet work with mainline,
this is not yet a conflict. It would be nice to have an alternative
fix for boards where this is a problem.
For example Sabre SD uses GPIO6 for I2C3_SDA. It also
has long ping times currently. But cannot use this fix
without giving up a touchscreen.
Its ping times are also random.
ping 192.168.0.19 -i.5 -c5
PING 192.168.0.19 (192.168.0.19) 56(84) bytes of data.
64 bytes from 192.168.0.19: icmp_req=1 ttl=64 time=16.0 ms
64 bytes from 192.168.0.19: icmp_req=2 ttl=64 time=15.4 ms
64 bytes from 192.168.0.19: icmp_req=3 ttl=64 time=14.4 ms
64 bytes from 192.168.0.19: icmp_req=4 ttl=64 time=13.4 ms
64 bytes from 192.168.0.19: icmp_req=5 ttl=64 time=12.4 ms
=== 192.168.0.19 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 12.451/14.369/16.057/1.316 ms
Signed-off-by: Troy Kisky <troy.ki...@boundarydevices.com>
CC: Ranjani Vaidyanathan <ra5...@freescale.com>
Signed-off-by: Shawn Guo <shawn....@linaro.org>
,but I am wondering if we should also do:
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -66,6 +66,7 @@
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc 0 118 IRQ_TYPE_LEVEL_HIGH>,
<&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
status = "okay";
};
@@ -226,7 +227,7 @@
MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
- MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
+ MX6QDL_PAD_GPIO_6__ENET_IRQ
0x400000b1
Since the Workaround for erratum ERR006687 states that the SION bit
needs to be used:
"All of the interrupts can be selected by MUX and output to pad GPIO6.
If GPIO6 is selected to
output ENET interrupts and GPIO6 SION is set, the resulting GPIO
interrupt will wake the system
from Wait mode."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
