1. 10 Feb, 2014 4 commits
    • Peter Chen's avatar
      ARM: dts: imx6: add anatop phandle for usbphy · 76a38855
      Peter Chen authored
      Add anatop phandle for usbphy
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      76a38855
    • Troy Kisky's avatar
      ARM: dts: imx6q-arm2: use GPIO_6 for FEC interrupt. · 4c2620e7
      Troy Kisky authored
      This works around a hardware bug.
      Signed-off-by: default avatarTroy Kisky <troy.kisky@boundarydevices.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      4c2620e7
    • Troy Kisky's avatar
      ARM: dts: imx6qdl-sabreauto: use GPIO_6 for FEC interrupt. · bc20a5d6
      Troy Kisky authored
      This works around a hardware bug.
      Signed-off-by: default avatarTroy Kisky <troy.kisky@boundarydevices.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      bc20a5d6
    • Troy Kisky's avatar
      ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt. · 6261c4c8
      Troy Kisky authored
      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: default avatarTroy Kisky <troy.kisky@boundarydevices.com>
      CC: Ranjani Vaidyanathan <ra5478@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      6261c4c8
  2. 09 Feb, 2014 36 commits