Stephen Rothwell reported that this driver does not compile on PowerPC
due to this missing include. One could argue why this driver is enabled
on PowerPC in the first place but it sure isn't wrong to include headers
for used function instead of to rely that they sneak in.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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>

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>

Some of the PHY parameters are not set according to the TRMs:

- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set
  properly
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>

This driver is a redo of my earlier attempt. It uses parts of the
generic PHY driver and uses the new control driver for the register
the phy needs to power on/off the phy. It also enables easy access for
the wakeup register which is not yet implemented.
The difference between the omap attempt is:
- no static holding variable
- one global visible function which exports a struct with callbacks to
  access the "control" registers.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch exports the mostly generic functions so they can be used from
other phy driver instead of duplicating the code.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The "nop" driver isn't a do-nothing-stub but supports a couple functions
like clock on/off or is able to use a voltage regulator. This patch
simply renames the driver to "generic" since it is easy possible to
extend it by a simple function istead of writing a complete driver.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When platform_driver_probe() is not used, bind/unbind via sysfs
is enabled.  Thus, __exit_p annotation should be removed from
remove().

Also, mv_otg_remove() is staticized, because this function is
used only in this file. Fix the following sparse warning:

drivers/usb/phy/phy-mv-usb.c:656:5: warning: symbol 'mv_otg_remove' was not declared. Should it be static?
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

mv_u3d_phy_shutdown() is used only in this file.
Fix the following sparse warning:

drivers/usb/phy/phy-mv-u3d-usb.c:85:6: warning: symbol 'mv_u3d_phy_shutdown' was not declared. Should it be static?
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use switch() instead of if-else when checking for the PHY type.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the new of_usb_get_dr_mode helper function for parsing dr_mode
from the device tree. Also replace the usage of the custom
tegra_usb_phy_mode enum with the standard enum.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the new of_usb_get_phy_mode helper function for parsing phy_type
from the device tree.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The Tegra EHCI driver is no longer using these custom functions, so they
can be removed.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Register the Tegra PHY device instances with the PHY subsystem so that
the Tegra EHCI driver can locate a PHY via the standard APIs.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

struct usb_phy already has a field for the device pointer, so this
unnecessary field can be removed.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The tegra ehci driver has enabled USB vbus regulators directly using
GPIOs and the device tree attribute nvidia,vbus-gpio. This is ugly
and causes error messages on boot when both the regulator driver
and the ehci driver want access to the same GPIO.

After this patch, usb vbus regulators for tegra usb phy devices are specified
with the device tree attribute vbus-supply = <&x> where x is a regulator defined
in the device tree. The old nvidia,vbus-gpio property is no longer supported.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

UTMIP parameters used to be hardcoded into tables in the
PHY driver. This patch reads them from the device tree instead
in accordance with the phy-tegra-usb DT documentation.
Signed-off-by: NMikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use a mapping table (dpll_map) to match the possible system clock rates
to the appropriate DPLL parameters.

Introduce a function "omap_usb3_get_dpll_params()" that will
return the matching DPLL parameters for the given clock rate.

Also, bail out on phy init if DPLL locking fails.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Convert PHY Drivers from menuconfig to menu so that the PHY drivers
can be explicitely selected by the controller drivers.

USB_PHY is no longer a user visible option. It is upto to the PHY
drivers to select it if needed. This patch does so for the existing
PHY drivers that use the USB_PHY library.

Doing so moves the USB_PHY and PHY driver selection problem from the
end user to the PHY and controller driver developer.

e.g.

Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select
a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver
depended on USB_PHY. Making the controller driver depend on USB_PHY
has a negative effect i.e. it becomes invisible to the user till
USB_PHY is enabled. Most end users will not familiar with this.

With this patch, the end user just needs to select the controller driver
needed for his/her platform without worrying about which PHY driver to
select.

Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend
on USB_PHY any more. They can safely select the necessary PHY drivers.

[ balbi@ti.com : refreshed on top of my next branch. Changed bool
	followed by default n into def_bool n ]

CC: Pavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

stmp_reset_block() may fail, so let's check its return value and propagate it
in the case of error.
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

commit 57f6ce07 ("usb: phy:
add a new driver for usb3 phy") added the new Kconfig option
OMAP_USB3, but it had no dependencies whatsoever, and hence
became available across all arch/platforms.

Which presumably caused this to show up in x86 randconfig:

    warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
        OMAP_CONTROL_USB which has unmet direct \
        dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)

Then commit 6992819f ("usb: phy:
fix Kconfig warning") was added.  However, this just deleted the
ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further
compounding the problem by opening up OMAP_CONTROL_USB to
all arch/platforms as well.

Earlier it was suggested[1] that we revert the change of 6992819f
to restore the dependency, and add a same ARCH_OMAP2PLUS dependency
to the new OMAP_USB3 entry.  However that was discouraged on the
grounds of people wanting the extra sanity compile testing on x86,
even though the driver could probably never be used there.

Now we have CONFIG_COMPILE_TEST, so developers who value the ability
to compile drivers on an architecture that it never can be used for
can have that, and people who want dependencies to shield them from
seeing options that aren't relevant to their platform get what they
want too.

Here we restore the dependency but couple it with COMPILE_TEST, in
order to achieve both of the above goals.

[1] https://patchwork.kernel.org/patch/2194511/Acked-by: NFelipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Moiz Sonasath <m-sonasath@ti.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that no USB phy driver is using CONFIG_USB_DEBUG, remove it from the
Makefile.
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the in-kernel pr_debug() calls instead of trying to roll your own
DBG macro.  This means the dynamic debugging calls now work here, and
there is no dependency on CONFIG_USB_DEBUG for the phy code anymore.
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Correction of the omap_usb3_dpll_params array when the sys_clk_rate is
20MHz.
Signed-off-by: NNikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: NRuchika Kharwar <ruchika@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The error message is common to both clk_get functions. Update it
accordingly.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add calls to clk_prepare and unprepare so that MSM can migrate to
the common clock framework.
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.

Currently there are no users of TWL6025 in the code.
Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NOleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Reviwed-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The previous text confused users by not describing the very common
(e.g. x86 PC) sitations where no PHY driver is necessary.
Signed-off-by: NGeorge Spelvin <linux@horizon.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

When this file is built as a module, it needs a MODULE_LICENSE in order
to access many exported symbols.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NThierry Reding <thierry.reding@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to build a ULPI PHY driver as a module, this symbol needs to
be exported.
Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NThierry Reding <thierry.reding@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 75096579 ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
CC: linux-usb@vger.kernel.org
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up  during USB-PHY  startup depending on
whether a ferrite bead is in use or not.  So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.

Also mark in the driver's Kconfig section  that R8A7778 is now supported and
generally clarify that section, uppercasing the word "phy" and also changing
the module name that got lost in the big driver rename, while at it...

The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in  rcar_usb_phy_shutdown()  anymore as that does not make
sense.  Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.

The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The memory region that is used by the driver overlaps EHCI and OHCI  register
regions for absolutely no reason now  -- fix it  by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...

Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...

The patch has been tested on the Marzen board.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Now that the EHCI internal  buffer setup is done by the platform code,  we  can
remove  such code from this driver as it  never  really belonged here.  We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).

The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>