1. 06 11月, 2012 1 次提交
  2. 20 9月, 2012 1 次提交
  3. 07 9月, 2012 1 次提交
    • S
      ARM: dt: tegra: paz00: add regulators · 217b8f0f
      Stephen Warren 提交于
      The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this.
      
      Three data sources were used for the data encoded here:
      * The HW defaults, as extracted from real HW.
      * The schematic, which specifies a voltage for each rail in the signal
        names.
      * The AC100 kernel used by the Ubuntu port:
      
        repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git
        branch chromeos-ac100-3.0
        file arch/arm/mach-tegra/board-paz00-power.c
      
        For many rails, the constraints in that tree specified differing min
        and max voltages. In all cases, the min value was ignored, since
        there's no need currently to vary any of the voltages at run-time.
        DVFS might change this in the future.
      
      In most cases these sources all matched. Differences are:
      
      sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max
      of 1.3v, but this higher voltage was only applied to HW by DVFS code,
      which isn't currently supported in mainline.
      
      sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
      of 1.125v, but this higher voltage was only applied to HW by DVFS code,
      which isn't currently supported in mainline.
      
      ldo3: The HW default is on. marvin24's kernel didn't specify always-on,
      but since the board wasn't marked as having fully constrained regulators,
      the rail was not turned off, so the difference had no effect. The rail
      is needed for USB.
      
      ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However,
      since this regulator is used for the same purpose as on other boards that
      require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT
      VDAC on Tegra, and so in practice is unlikely to be used, even though it
      is actaully hooked up in HW.
      
      Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: Marc Dietrich <marvin24@gmx.de> # v2
      Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
      217b8f0f
  4. 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
  5. 12 6月, 2012 1 次提交
  6. 15 5月, 2012 7 次提交
  7. 26 4月, 2012 2 次提交
    • S
      ARM: dt: tegra: pinmux changes for USB ULPI · 563da21b
      Stephen Warren 提交于
      Ensure that the USB ULPI signals are not tri-stated, and have no pull-
      up or pull-down.
      
      Ensure that the pingroup hosting the USB ULPI reset signal (GPIO PV0 or
      PV1 depending on the board, so UAC) is not tri-stated, and has no pull-
      up or pull-down.
      
      This change appears larger than it is due to the grouping and sorting of
      the pin configuration data.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      563da21b
    • 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
  8. 19 4月, 2012 1 次提交
  9. 05 3月, 2012 1 次提交
  10. 07 2月, 2012 10 次提交
  11. 08 12月, 2011 4 次提交