An error occurred fetching the project authors.
  1. 09 Aug, 2016 1 commit
  2. 11 Jun, 2016 2 commits
  3. 27 Apr, 2016 1 commit
  4. 19 Oct, 2015 4 commits
  5. 11 Aug, 2015 1 commit
  6. 24 Jul, 2015 1 commit
  7. 15 Jul, 2015 1 commit
  8. 03 Jun, 2015 1 commit
  9. 05 Jan, 2015 3 commits
  10. 18 Jul, 2014 1 commit
    • Markus Pargmann's avatar
      ARM: dts: imx: remove ssi fsl,mode for audio cards · 9eb0e5f9
      Markus Pargmann authored
      The DAI mode is and should be configured by the sound card driver as
      codec and ssi have to be in the right modes to communicate with each
      other. It is possible to operate the ssi unit or the codec in master mode,
      sometimes even on the same board in different configurations.
      
      With the latest changes in the fsl-ssi driver, the 'fsl,mode' property
      is only handled as a fallback property. If the sound card sets the DAI
      mode correctly, this fallback configuration is dropped.
      Signed-off-by: default avatarMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarShawn Guo <shawn.guo@freescale.com>
      9eb0e5f9
  11. 16 May, 2014 1 commit
  12. 10 Feb, 2014 1 commit
    • 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
  13. 09 Feb, 2014 21 commits
  14. 29 Sep, 2013 1 commit