1. 13 11月, 2014 1 次提交
  2. 20 2月, 2014 1 次提交
  3. 19 12月, 2013 1 次提交
  4. 17 12月, 2013 3 次提交
  5. 13 8月, 2013 1 次提交
  6. 29 5月, 2013 4 次提交
  7. 18 5月, 2013 2 次提交
  8. 05 4月, 2013 5 次提交
  9. 04 4月, 2013 1 次提交
  10. 12 3月, 2013 1 次提交
  11. 29 1月, 2013 4 次提交
  12. 16 11月, 2012 3 次提交
  13. 06 11月, 2012 1 次提交
  14. 12 9月, 2012 1 次提交
  15. 07 9月, 2012 1 次提交
    • S
      ARM: dt: tegra: ventana: add regulators · 017a0104
      Stephen Warren 提交于
      Ventana uses a TPS6586x regulator. Instantiate this, and hook up a
      couple of fixed GPIO-controlled regulators too.
      
      The data was chosen to match the PMIC HW defaults, with the following
      exception:
      
      ldo6: The HW default is 2.85v. The schematics are unlabelled. Internal
      research indicates that 1.8v is correct. Our downstream kernel also uses
      1.8v.
      
      Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      017a0104
  16. 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
  17. 12 6月, 2012 1 次提交
  18. 15 5月, 2012 6 次提交
  19. 04 5月, 2012 1 次提交
  20. 26 4月, 2012 1 次提交
    • S
      ARM: tegra: add USB ULPI PHY reset GPIO to device tree · aa607ebf
      Stephen Warren 提交于
      ULPI PHYs have a reset signal, and different boards use a different GPIO
      for this task. Add a property to device tree to represent this.
      
      I'm not sure if adding this property to the EHCI controller node is
      entirely correct; perhaps eventually we should have explicit separate
      nodes for the various PHYs. However, we don't have that right now, so this
      binding seems like a reasonable choice.
      
      Cc: <devicetree-discuss@lists.ozlabs.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <linux-usb@vger.kernel.org>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      aa607ebf