From patchwork Thu Jul 5 08:42:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ruslan Bilovol X-Patchwork-Id: 1158621 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id B3DD0DFB7C for ; Thu, 5 Jul 2012 08:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753107Ab2GEImX (ORCPT ); Thu, 5 Jul 2012 04:42:23 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:51233 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437Ab2GEImW (ORCPT ); Thu, 5 Jul 2012 04:42:22 -0400 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id q658gLNH005336; Thu, 5 Jul 2012 03:42:21 -0500 Received: from DFLE70.ent.ti.com (dfle70.ent.ti.com [128.247.5.40]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q658gL2D007043; Thu, 5 Jul 2012 03:42:21 -0500 Received: from dlelxv22.itg.ti.com (172.17.1.197) by dfle70.ent.ti.com (128.247.5.40) with Microsoft SMTP Server id 14.1.323.3; Thu, 5 Jul 2012 03:42:21 -0500 Received: from localhost (uglx0155540.ucm2.emeaucm.ext.ti.com [10.167.145.75]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id q658gKqn030368; Thu, 5 Jul 2012 03:42:21 -0500 From: Ruslan Bilovol To: , , Subject: [PATCH 2/2] OMAP4: otg: phy: remove uggly mdelay(200) Date: Thu, 5 Jul 2012 11:42:19 +0300 Message-ID: <1341477739-6801-1-git-send-email-ruslan.bilovol@ti.com> X-Mailer: git-send-email 1.7.1 MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org 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 --- 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);