summaryrefslogtreecommitdiffstats
path: root/arch/um/Makefile-skas
diff options
context:
space:
mode:
authorTroy Kisky <troy.kisky@boundarydevices.com>2013-12-20 19:47:11 +0100
committerShawn Guo <shawn.guo@linaro.org>2014-02-10 09:25:00 +0100
commit6261c4c8f13eb91f733e8ba6d67c409a2e841667 (patch)
tree57c0648ce5dac7fcfe73e2375d528a178d9b8cbc /arch/um/Makefile-skas
parentARM: dts: imx6qdl: use interrupts-extended for fec (diff)
downloadlinux-6261c4c8f13eb91f733e8ba6d67c409a2e841667.tar.xz
linux-6261c4c8f13eb91f733e8ba6d67c409a2e841667.zip
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.kisky@boundarydevices.com> CC: Ranjani Vaidyanathan <ra5478@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Diffstat (limited to 'arch/um/Makefile-skas')
0 files changed, 0 insertions, 0 deletions