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

USB VBUS regulators are now specified with the vbus-supply property
instead of nvidia,vbus-gpio, so remove the obsolete properties.

The equivalent vbus-supply properties were already added in patch
"ARM: tegra: update device trees for USB binding rework".
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Document vbus-supply as an optional property for host mode phy-tegra-usb PHYs.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe 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: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe 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: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This patch changes the Tegra20 USB PHY nodes to use the UTMI configuration
parameter names as specified in the device tree binding documentation
after patch "ARM: tegra: finalize USB EHCI and PHY bindings".
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Commit 8d2421e6 ("usb: musb: kill global and static for multi instance")
removed the global dma_mask copy and replaced by parent's DMA mask. The
problem here is that if the parent does not have a dma_mask then
musb_remove() goes kaboom.
Instead trying to fix this I was thinking we do we need to erase
dma_mask in the first place?
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

ti81xx does not have a baseport mainline i.e. it should not boot. The
amount of rework that is required makes it easier to simply remove that
platform (i.e. that possible platform device) and add it later once it
comes back with DT support.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

If the init / shutdown function of the phy moves out of dsps into the
phy driver, then dsps needs to call the callbacks of the phy driver to
ensure that this happens.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe 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: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Current usbhsx_for_each_xxx macro will read out-of-array's
memory after last loop operation.
It was not good C language operation, and the binary which was
compiled by (at least) gcc 4.8.1 is broken
This patch tidyup these issues
Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Reviewed-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe 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: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

ehci-omap needs NOP_USB_XCEIV PHY driver to function
properly, so select it. As the USB PHY drivers no longer
depend on USB_PHY, it is safe to select the PHY drivers.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Felipe 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: Roland Stigge <stigge@antcom.de>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

before changing to configured state, we need
to wait until gadget driver has had a chance
to process the request.

In case of USB_GADGET_DELAYED_STATUS, that means
we need to defer usb_gadget_set_state() until
the upcoming usb_ep_queue().
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>

In case we're switching back to USB_STATE_ADDRESS
from USB_STATE_CONFIGURED (if host sends
a set configuration command for configuration
zero), we should only switch if the request
is successfully processed by the gadget driver.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb_gadget_set_state() will call sysfs_notify()
which might sleep. Some users might want to call
usb_gadget_set_state() from the very IRQ handler
which actually changes the gadget state.

Instead of having every UDC driver add their own
workqueue for such a simple notification, we're
adding it generically to our struct usb_gadget,
so the details are hidden from all UDC drivers.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Change intervall into interval.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

in order to make our IRQ handler thread easier
to read, we re-factor the inner loop to a separate
function.
Signed-off-by: Felipe Balbi <balbi@ti.com>

that function isn't really processing any event
buffer, rather just checking whether it contains
events to be processed.

Due to that reason, we're reaning it to dwc3_check_event_buf()
instead.
Signed-off-by: Felipe Balbi <balbi@ti.com>

We can make use of bit 31 of the GEVNTSIZ(n)
registers to mask/unmask interrupts from that
particular interrupter.

With that feature, we can easily drop IRQF_ONESHOT
from our driver which makes it possible to
properly change IRQ priorities when using RT
patchset *and* it allows us to make use of the
scheduler to choose the proper time to handle
this IRQ thread.
Signed-off-by: Felipe Balbi <balbi@ti.com>

That register has more than just the event buffer
size; we can also mask and unmask that particular
interrupter on bit 31 of that register.

In this patch we introduce the necessary macros
and make sure to use the new macros while also
making sure we mask interrupts during driver
removal.
Signed-off-by: Felipe Balbi <balbi@ti.com>

LPM is enabled in Connection Done interrupt,
there's no need to enable it early.
Signed-off-by: Felipe Balbi <balbi@ti.com>

the macro DWC3_DCFG_LPM_CAP was defined twice.

This patch just removes one of the definitions,
no functional changes.
Signed-off-by: Felipe Balbi <balbi@ti.com>

that way we get debugging information when
enabling verbose debug of the driver.

It will be no-op otherwise.
Signed-off-by: Felipe Balbi <balbi@ti.com>

no functional changes, just grouping dep
initialization.
Signed-off-by: Felipe Balbi <balbi@ti.com>

by moving that dev_vdbg() to the internal
__dwc3_gadget_ep_enable() we get the print
even when enable ep0, which calls the internal
function directly.
Signed-off-by: Felipe Balbi <balbi@ti.com>

use the new devm_ioremap_resource() on core.c
Signed-off-by: Felipe Balbi <balbi@ti.com>

use the new devm_ioremap_resource on dwc3-omap.c
Signed-off-by: Felipe Balbi <balbi@ti.com>

Recent versions of the core, can suspend and resume
the PHYs automatically, so we don't need to fiddle
with dwc3's Global PHY registers at all.

On versions prior to 1.94a this patch will mean
that we will never ask dwc3 to suspend the PHY.

This is an acceptable behavior or such old versions
of the core, specially considering that the only
chip known to have a version prior to 1.94a was
OMAP5 ES1.0 and that's not supported in mainline
kernel, because it was just a test spin of OMAP5.
Signed-off-by: Felipe Balbi <balbi@ti.com>

This patch adapts the dwc3 to use the device tree helper
"of_usb_get_dr_mode" for the mode of operation of the dwc3 instance
being probed.

[ balbi@ti.com : make of_usb_get_dr_mode() conditional on
	dev->of_node and let pdata pass dr_mode too ]
Reviewed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe 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: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

The musb driver no longer uses procfs, so get rid of the proc_dir_entry
variable in struct musb.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

all other drivers using Synopsys IPs with DT
have a compatible of snps,$driver, in order
to add consistency, we are switching over to
snps,dwc3 but keeping synopsys,dwc3 in the core
driver to maintain backwards compatibility.

New DTS bindings should NOT use synopsys,dwc3.
Signed-off-by: Felipe Balbi <balbi@ti.com>

in order to allow different instances of the
core work in different maximum speeds, we will
move the maximum_speed module_parameter to
both DeviceTree (making use the new maximum-speed
DT property) and platform_data.
Signed-off-by: Felipe Balbi <balbi@ti.com>

in case we're not in a DT boot, we should
still be able to tell the driver how to behave.

In order to be able to pass flags to the driver,
we introduce platform_data structure which the
core driver should use.
Signed-off-by: Felipe Balbi <balbi@ti.com>

this helper will be used for controllers which
want to work at a lower speed even though they
support higher USB transfer rates.

One such case is Texas Instruments' AM437x
SoC where it uses a USB3 controller without
a USB3 PHY, rendering the controller USB2-only.
Signed-off-by: Felipe Balbi <balbi@ti.com>

In order to decrease the amount of work done
by PHY users, allow NULL phy pointers to be
passed.
Signed-off-by: Felipe Balbi <balbi@ti.com>