- 30 Jul, 2013 5 commits
-
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Jingoo Han authored
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Mikko Perttunen authored
The device tree binding documentation for tegra20-usb-phy used to claim that the vbus-supply property is required for host phys and optional for otg phys. This should be the other way around. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
commit 052a11d1 (usb: phy: make PHY driver selection possible by controller drivers) changed the rules on how drivers/usb/phy/of.c would be compiled and failed to update include/linux/usb/of.h accordingly. Because of that, we can fall into situations where of_usb_get_phy_mode() is redefined. In order to fix the error, we update the IS_ENABLED() check in include/linux/usb/of.h to reflect the condition where of.c is built. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 29 Jul, 2013 35 commits
-
-
Ivan T. Ivanov authored
When deferred probe happens driver will try to ioremap multiple times and will fail. Memory resource.start variable is a global variable, modifications in this field will be accumulated on every probe. Fix this by moving the above operations after driver hold all required PHY's. Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Tuomas Tynkkynen authored
Use switch() instead of if-else when checking for the PHY type. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
The EOI register is not present in the AM335x memory space according to the TRM and thus removed. Should any platform using the EOI register get merged then it may be used again if the register address is not zero. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Sebastian Andrzej Siewior authored
The ti81xx platform is not fully supported right now. This patch renames the date structure to a am33xx prefix which is actually used. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Tuomas Tynkkynen authored
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: 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>
-
Tuomas Tynkkynen authored
Use the new of_usb_get_phy_mode helper function for parsing phy_type from the device tree. 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>
-
Tuomas Tynkkynen authored
The Tegra EHCI driver is no longer using these custom functions, so they 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>
-
Tuomas Tynkkynen authored
Use devm_get_phy_by_phandle to get a PHY device instead of the custom Tegra functions. 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>
-
Tuomas Tynkkynen authored
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: 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>
-
Tuomas Tynkkynen authored
USB-related platform data is not used anymore in the Tegra USB drivers, so remove all of it. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Tuomas Tynkkynen authored
Platform data is not used in tegra-ehci anymore, so remove all references to it. 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>
-
Tuomas Tynkkynen authored
ehci-tegra calls devm_usb_get_phy, which will never succeed since the Tegra PHY does not register itself with the PHY subsystem. It is also completely redundant since the code has already located a PHY via an internal API. Call otg_set_host unconditionally to simplify the code since it should be safe to do so. 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>
-
Tuomas Tynkkynen authored
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>
-
Mikko Perttunen authored
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>
-
Mikko Perttunen authored
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>
-
Mikko Perttunen authored
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>
-
Mikko Perttunen authored
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>
-
Mikko Perttunen authored
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>
-
Sebastian Andrzej Siewior authored
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>
-
Sebastian Andrzej Siewior authored
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>
-
Sebastian Andrzej Siewior authored
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>
-
Wolfram Sang authored
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>
-
Boris BREZILLON authored
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>
-
Kuninori Morimoto authored
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>
-
Roger Quadros authored
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>
-
Roger Quadros authored
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>
-
Roger Quadros authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Huang Rui authored
Change intervall into interval. Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-