1. 13 8月, 2013 2 次提交
    • T
      usb: phy: tegra: Program new PHY parameters · e497a24d
      Tuomas Tynkkynen 提交于
      The Tegra30 TRM recommends configuration of certain PHY parameters for
      optimal quality. Program the following registers based on device tree
      parameters:
      
      - UTMIP_XCVR_HSSLEW: HS slew rate control.
      - UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
      - UTMIP_HSDISCON_LEVEL: HS disconnect detector level.
      
      These registers exist in Tegra20, but programming them hasn't been
      necessary, so these parameters won't be set on Tegra20 to keep the
      device trees backward compatible.
      
      Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
      instead of a software-programmed value, as the optimal value can
      vary between invidual boards. The boolean property
      nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.
      Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e497a24d
    • T
      usb: phy: tegra: Tegra30 support · 3e635202
      Tuomas Tynkkynen 提交于
      The Tegra30 USB PHY is a bit different than the Tegra20 PHY:
      
      - The EHCI controller supports the HOSTPC register extension, and some
        of the fields that the PHY needs to modify (PHCD and PTS) have moved
        to the new HOSTPC register.
      - Some of the UTMI PLL configuration registers have moved from the USB
        register space to the Clock-And-Reset controller space. In Tegra30
        the clock driver is responsible for configuring the UTMI PLL.
      - The USBMODE register must be explicitly written to enter host mode.
      - Certain PHY parameters need to be programmed for optimal signal
        quality. Support for this will be added in the next patch.
      
      The new tegra_phy_soc_config structure is added to describe the
      differences between the SoCs.
      Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      3e635202
  2. 29 7月, 2013 5 次提交
  3. 18 6月, 2013 1 次提交
    • S
      USB: EHCI: tegra: fix circular module dependencies · 91a687d8
      Stephen Warren 提交于
      The Tegra EHCI driver directly calls various functions in the Tegra USB
      PHY driver. The reverse is also true; the PHY driver calls into the EHCI
      driver. This is problematic when the two are built as modules.
      
      The calls from the PHY to EHCI driver were originally added in commit
      bbdabdb6 "usb: add APIs to access host registers from Tegra PHY", for the
      following reasons:
      
      1) The register being touched is an EHCI register, so logically only the
         EHCI driver should touch it.
      2) (1) implies that some locking may be needed to correctly implement the
         r/m/w access to this shared register.
      3) We were expecting to pass only the PHY register space to the Tegra PHY
         driver, and hence it would not have access to touch the shared
         registers.
      
      To solve this, that commit added functions in the EHCI driver to touch the
      shared register on behalf of the PHY driver.
      
      In practice, we ended up not having any locking in the implementaiton of
      those functions, and I've been led to believe this is safe. Equally, (3)
      did not happen either. Hence, it is possible for the PHY driver to touch
      the shared register directly.
      
      Given that, this patch moves the code to touch the shared register back
      into the PHY driver, to eliminate the module problems. If we actually
      need locking or co-ordination in the future, I propose we put the lock
      support into some pre-existing core module, or into a third separate
      module, in order to avoid the circular dependencies.
      
      I apologize for my contribution to code churn here.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Tested-by: NThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91a687d8
  4. 30 5月, 2013 3 次提交
  5. 24 4月, 2013 1 次提交
    • A
      usb: phy: tegra: don't call into tegra-ehci directly · ee5d5499
      Arnd Bergmann 提交于
      Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
      which does not work if one of them or both are loadable modules, resulting
      in an error like:
      
      drivers/built-in.o: In function `utmi_phy_clk_disable':
      drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to `tegra_ehci_set_phcd'
      drivers/built-in.o: In function `utmi_phy_clk_enable':
      drivers/usb/phy/phy-tegra-usb.c:324: undefined reference to `tegra_ehci_set_phcd'
      drivers/built-in.o: In function `utmi_phy_power_on':
      drivers/usb/phy/phy-tegra-usb.c:447: undefined reference to `tegra_ehci_set_pts'
      
      This turns the interface into a one-way dependency by letting the tegra ehci
      driver pass two function pointers for callbacks that need to be called by
      the phy driver.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Venu Byravarasu <vbyravarasu@nvidia.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee5d5499
  6. 29 1月, 2013 5 次提交
  7. 05 9月, 2012 1 次提交
  8. 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
  9. 13 2月, 2012 1 次提交
  10. 12 3月, 2011 1 次提交
新手
引导
客服 返回
顶部