| Message ID | 1341477739-6801-1-git-send-email-ruslan.bilovol@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol <ruslan.bilovol@ti.com> wrote: > 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 So is this 200ms delay related to incorrect charger detection? How is it now fixed without the delay? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, Aug 3, 2012 at 9:51 AM, ABRAHAM, KISHON VIJAY <kishon@ti.com> wrote: > > Hi, > > On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol <ruslan.bilovol@ti.com> > wrote: > > 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 > > So is this 200ms delay related to incorrect charger detection? How is > it now fixed without the delay? Please take a look at the first patch of this series: http://markmail.org/message/vlbk7glkyviviipw It fixes charger detection feature usage. -- Best regards, Ruslan Bilovol -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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@ti.com> --- arch/arm/mach-omap2/omap_phy_internal.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-)