1. 13 11月, 2014 1 次提交
  2. 18 7月, 2014 1 次提交
  3. 17 6月, 2014 1 次提交
  4. 19 12月, 2013 1 次提交
  5. 17 12月, 2013 3 次提交
  6. 22 8月, 2013 1 次提交
    • S
      ARM: tegra: always enable USB VBUS regulators · 30ca2226
      Stephen Warren 提交于
      This fixes a regression exposed during the merge window by commit
      9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
      USB VBUS doesn't get turned on, so USB devices are not detected. This
      affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
      which the SSD is connected) and the external port(s) on Seaboard/
      Springbank and Whistler.
      
      The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:
      
      1) Via the legacy DT binding for the USB controller; it can directly
         acquire a VBUS GPIO and activate it.
      
      2) Via a regulator for VBUS, which is referenced by the new DT binding
         for the USB controller.
      
      Those two methods both use the same GPIO, and hence whichever of the
      USB controller and regulator gets probed first ends up owning the GPIO.
      In practice, the USB driver only supports path (1) above, since the
      patches to support the new USB binding are not present until v3.12:-(
      
      In practice, the regulator ends up being probed first and owning the
      GPIO. Since nothing enables the regulator (the USB driver code is not
      yet present), the regulator ends up being turned off. This originally
      caused no problem, because the polarity in the regulator definition was
      incorrect, so attempting to turn off the regulator actually turned it
      on, and everything worked:-(
      
      However, when testing the new USB driver code in v3.12, I noticed the
      incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
      regulator GPIO polarity in DT". In the context of v3.11, this patch then
      caused the USB VBUS to actually turn off, which broke USB ports with VBUS
      control. I got this patch included in v3.11-rc1 since it fixed a bug in
      device tree (incorrect polarity specification), and hence was suitable to
      be included early in the rc series. I evidently did not test the patch at
      all, or correctly, in the context of v3.11, and hence did not notice the
      issue that I have explained above:-(
      
      Fix this by making the USB VBUS regulators always enabled. This way, if
      the regulator owns the GPIO, it will always be turned on, even if there
      is no USB driver code to request the regulator be turned on. Even
      ignoring this bug, this is a reasonable way to configure the HW anyway.
      
      If this patch is applied to v3.11, it will cause a couple pretty trivial
      conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
      the context right above the added lines changed in patches destined for
      v3.12.
      Reported-by: NKyle McMartin <kmcmarti@redhat.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      30ca2226
  7. 13 8月, 2013 2 次提交
  8. 02 8月, 2013 1 次提交
  9. 29 7月, 2013 1 次提交
  10. 03 7月, 2013 1 次提交
  11. 29 5月, 2013 3 次提交
  12. 18 5月, 2013 2 次提交
  13. 05 4月, 2013 4 次提交
  14. 04 4月, 2013 1 次提交
  15. 12 3月, 2013 1 次提交
  16. 29 1月, 2013 3 次提交
  17. 17 11月, 2012 1 次提交
  18. 16 11月, 2012 1 次提交
  19. 26 7月, 2012 2 次提交
  20. 21 6月, 2012 1 次提交
    • S
      ARM: dt: tegra: rename board files to match SoC · 702b0e4f
      Stephen Warren 提交于
      Most ARM ${board}.dts files are already named ${soc}-${board}.dts. This
      change modifies the Tegra board files to be named the same way for
      consistency.
      
      Once a related change is made in U-Boot, this will cause both U-Boot and
      the kernel to use the same names for the .dts files and SoC identifiers,
      thus allowing U-Boot's recently added "soc" and "board" environment
      variables to be used to construct the name of Tegra .dtb files, and hence
      allow board-generic U-Boot bootcmd scripts to be written.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      702b0e4f
  21. 15 5月, 2012 5 次提交
  22. 04 5月, 2012 3 次提交