The original issue with powering on the PHY (and using
200 ms delay after this) is not related to internal
processes in the PHY but is in the incorrect charger
detection feature usage.
Now when it is fixed, we can safely remove this uggly
mdelay that sometimes was called in atomic context and
leads to unacceptable system freezing
Tested with different hubs, devices, and booting scenarios.
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@xxxxxx>
---
arch/arm/mach-omap2/omap_phy_internal.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
index a13a37c..0a59268 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -152,10 +152,8 @@ int omap4430_phy_suspend(struct device *dev, int suspend)
/* Enable the internel phy clcoks */
omap4430_phy_set_clk(dev, 1);
/* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
+ if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD)
__raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
/* restore the context */
__raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
