1. 25 Apr, 2012 8 commits
    • Stephen Warren's avatar
      ARM: dt: tegra: pinmux changes for USB ULPI · 563da21b
      Stephen Warren authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      563da21b
    • Stephen Warren's avatar
      ARM: tegra: add USB ULPI PHY reset GPIO to device tree · aa607ebf
      Stephen Warren authored
      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: default avatarStephen Warren <swarren@nvidia.com>
      aa607ebf
    • Stephen Warren's avatar
      ARM: tegra: don't hard-code USB ULPI PHY reset_gpio · 60d148b9
      Stephen Warren authored
      Not all boards use GPIO_PV0 as the ULPI PHY reset signal. Instead of
      hard-coding this GPIO into devices.c, make the board files set it
      explicitly. This will allow the PHY code to differentiate between set and
      unset values, and hence know when to read the value from device tree.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      60d148b9
    • Stephen Warren's avatar
      ARM: tegra: change pll_p_out4's rate to 24MHz · 9abafa02
      Stephen Warren authored
      pll_p_out4 is used on all/most Tegra boards to drive the cdev2 output pin
      to provide a reference clock to a ULPI USB PHY. This reference clock must
      run at 24MHz, and the cdev2 output has no additional dividers.
      
      Remove board-paz00.c's now-duplicate initialization of this clock.
      Reported-by: default avatarMarc Dietrich <marvin24@gmx.de>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      9abafa02
    • Stephen Warren's avatar
      ARM: tegra: fix pclk rate · 7ff4db09
      Stephen Warren authored
      Commit 40f9cf0 "ARM: tegra: reparent sclk to pll_c_out1" changed the
      rate of hclk. Since pclk is derived from that, and only has integer
      dividers, the pclk rate needs to change in the same fashion, from 54MHz
      to 60MHz.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      7ff4db09
    • Stephen Warren's avatar
      ARM: tegra: reparent sclk to pll_c_out1 · 60f975b9
      Stephen Warren authored
      pll_p_out4 needs to be used for other purposes. Reparent sclk so that
      it runs from pll_c. Change sclk's rate to 120MHz from 108MHz since this
      is the lowest precise rate that can be achieved by dividing the pll_c
      rate without reducing the sclk rate. (600/5=120, 600/5.5=109.0909...,
      600/6=100).
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      60f975b9
    • Allen Martin's avatar
      ARM: tegra: Add pllc clock init table · c8b62ab4
      Allen Martin authored
      pll_c will be used as a clock source. Fill in tegra_pll_c_freq_table[]
      so that it's possible to explicitly initialize the PLL.
      
      NVIDIA's downstream nv-3.1 kernel and the ChromeOS kernel have different
      pll_c tables. nv-3.1 contains entries for 522MHz and 598MHz output,
      whereas the ChromeOS kernel contains entries for 600MHz output. I chose
      to upstream the ChromeOS values for now, since the 600MHz rate appears
      to match the default rate of this PLL when the HW boots, and it's not
      clear to me why 522 or 598MHz are more useful.
      Signed-off-by: default avatarAllen Martin <amartin@nvidia.com>
      Signed-off-by: default avatarOlof Johansson <olofj@chromium.org>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      [swarren: wrote commit description]
      c8b62ab4
    • Stephen Warren's avatar
      pinctrl: tegra: error reporting cleanup · aef7704c
      Stephen Warren authored
      Print an explicit error message in various failure cases to allow
      easier diagnosis.
      
      WARN_ON() some internal failures that users/clients shouldn't be able to
      trigger.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      aef7704c
  2. 18 Apr, 2012 32 commits