[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Keshava Munegowda]

This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)" is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.

This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.

Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/host/ehci-omap.c |  164 +-----------------------------------------
 1 file changed, 1 insertion(+), 163 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17cfb8a..272e661 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
 #define	EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT		8
 #define	EHCI_INSNREG05_ULPI_WRDATA_SHIFT		0
 
-/* Errata i693 */
-static struct clk	*utmi_p1_fck;
-static struct clk	*utmi_p2_fck;
-static struct clk	*xclk60mhsp1_ck;
-static struct clk	*xclk60mhsp2_ck;
-static struct clk	*usbhost_p1_fck;
-static struct clk	*usbhost_p2_fck;
-static struct clk	*init_60m_fclk;
-
 /*-------------------------------------------------------------------------*/
 
 static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
 	return __raw_readl(base + reg);
 }
 
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
-	int ret = 0;
-
-	/* Switch to the internal 60 MHz clock */
-	ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
-	if (ret != 0)
-		ehci_err(ehci, "init_60m_fclk set parent"
-			"failed error:%d\n", ret);
-
-	ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
-	if (ret != 0)
-		ehci_err(ehci, "init_60m_fclk set parent"
-			"failed error:%d\n", ret);
-
-	clk_enable(usbhost_p1_fck);
-	clk_enable(usbhost_p2_fck);
-
-	/* Wait 1ms and switch back to the external clock */
-	mdelay(1);
-	ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
-	if (ret != 0)
-		ehci_err(ehci, "xclk60mhsp1_ck set parent"
-			"failed error:%d\n", ret);
-
-	ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
-	if (ret != 0)
-		ehci_err(ehci, "xclk60mhsp2_ck set parent"
-			"failed error:%d\n", ret);
-
-	clk_disable(usbhost_p1_fck);
-	clk_disable(usbhost_p2_fck);
-}
 
 static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
 {
@@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
 	}
 }
 
-static int omap_ehci_hub_control(
-	struct usb_hcd	*hcd,
-	u16		typeReq,
-	u16		wValue,
-	u16		wIndex,
-	char		*buf,
-	u16		wLength
-)
-{
-	struct ehci_hcd	*ehci = hcd_to_ehci(hcd);
-	u32 __iomem *status_reg = &ehci->regs->port_status[
-				(wIndex & 0xff) - 1];
-	u32		temp;
-	unsigned long	flags;
-	int		retval = 0;
-
-	spin_lock_irqsave(&ehci->lock, flags);
-
-	if (typeReq == SetPortFeature && wValue == USB_PORT_FEAT_SUSPEND) {
-		temp = ehci_readl(ehci, status_reg);
-		if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) {
-			retval = -EPIPE;
-			goto done;
-		}
-
-		temp &= ~PORT_WKCONN_E;
-		temp |= PORT_WKDISC_E | PORT_WKOC_E;
-		ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
-		omap_ehci_erratum_i693(ehci);
-
-		set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
-		goto done;
-	}
-
-	spin_unlock_irqrestore(&ehci->lock, flags);
-
-	/* Handle the hub control events here */
-	return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
-	spin_unlock_irqrestore(&ehci->lock, flags);
-	return retval;
-}
-
 static void disable_put_regulator(
 		struct ehci_hcd_omap_platform_data *pdata)
 {
@@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 	/* root ports should always stay powered */
 	ehci_port_power(omap_ehci, 1);
 
-	/* get clocks */
-	utmi_p1_fck = clk_get(dev, "utmi_p1_gfclk");
-	if (IS_ERR(utmi_p1_fck)) {
-		ret = PTR_ERR(utmi_p1_fck);
-		dev_err(dev, "utmi_p1_gfclk failed error:%d\n",	ret);
-		goto err_add_hcd;
-	}
-
-	xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
-	if (IS_ERR(xclk60mhsp1_ck)) {
-		ret = PTR_ERR(xclk60mhsp1_ck);
-		dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
-		goto err_utmi_p1_fck;
-	}
-
-	utmi_p2_fck = clk_get(dev, "utmi_p2_gfclk");
-	if (IS_ERR(utmi_p2_fck)) {
-		ret = PTR_ERR(utmi_p2_fck);
-		dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
-		goto err_xclk60mhsp1_ck;
-	}
-
-	xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
-	if (IS_ERR(xclk60mhsp2_ck)) {
-		ret = PTR_ERR(xclk60mhsp2_ck);
-		dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
-		goto err_utmi_p2_fck;
-	}
-
-	usbhost_p1_fck = clk_get(dev, "usb_host_hs_utmi_p1_clk");
-	if (IS_ERR(usbhost_p1_fck)) {
-		ret = PTR_ERR(usbhost_p1_fck);
-		dev_err(dev, "usbhost_p1_fck failed error:%d\n", ret);
-		goto err_xclk60mhsp2_ck;
-	}
-
-	usbhost_p2_fck = clk_get(dev, "usb_host_hs_utmi_p2_clk");
-	if (IS_ERR(usbhost_p2_fck)) {
-		ret = PTR_ERR(usbhost_p2_fck);
-		dev_err(dev, "usbhost_p2_fck failed error:%d\n", ret);
-		goto err_usbhost_p1_fck;
-	}
-
-	init_60m_fclk = clk_get(dev, "init_60m_fclk");
-	if (IS_ERR(init_60m_fclk)) {
-		ret = PTR_ERR(init_60m_fclk);
-		dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
-		goto err_usbhost_p2_fck;
-	}
 
 	return 0;
 
-err_usbhost_p2_fck:
-	clk_put(usbhost_p2_fck);
-
-err_usbhost_p1_fck:
-	clk_put(usbhost_p1_fck);
-
-err_xclk60mhsp2_ck:
-	clk_put(xclk60mhsp2_ck);
-
-err_utmi_p2_fck:
-	clk_put(utmi_p2_fck);
-
-err_xclk60mhsp1_ck:
-	clk_put(xclk60mhsp1_ck);
-
-err_utmi_p1_fck:
-	clk_put(utmi_p1_fck);
-
 err_add_hcd:
 	disable_put_regulator(pdata);
 	pm_runtime_put_sync(dev);
@@ -452,14 +298,6 @@ static int ehci_hcd_omap_remove(struct platform_device *pdev)
 	iounmap(hcd->regs);
 	usb_put_hcd(hcd);
 
-	clk_put(utmi_p1_fck);
-	clk_put(utmi_p2_fck);
-	clk_put(xclk60mhsp1_ck);
-	clk_put(xclk60mhsp2_ck);
-	clk_put(usbhost_p1_fck);
-	clk_put(usbhost_p2_fck);
-	clk_put(init_60m_fclk);

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
<keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> the usb hub and device detection fails in beagle XM
> causeing NFS not functional. This affects the core retention too.
> The same commit logic needs to be revisted adhering to hwmod and
> device tree framework.
> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>
> This patch is validated on BeagleXM with NFS support over
> usb ethernet and USB mass storage and other device detection.
>
> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/usb/host/ehci-omap.c |  164 +-----------------------------------------
>  1 file changed, 1 insertion(+), 163 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index 17cfb8a..272e661 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -56,15 +56,6 @@
>  #define        EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT             8
>  #define        EHCI_INSNREG05_ULPI_WRDATA_SHIFT                0
>
> -/* Errata i693 */
> -static struct clk      *utmi_p1_fck;
> -static struct clk      *utmi_p2_fck;
> -static struct clk      *xclk60mhsp1_ck;
> -static struct clk      *xclk60mhsp2_ck;
> -static struct clk      *usbhost_p1_fck;
> -static struct clk      *usbhost_p2_fck;
> -static struct clk      *init_60m_fclk;
> -
>  /*-------------------------------------------------------------------------*/
>
>  static const struct hc_driver ehci_omap_hc_driver;
> @@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
>        return __raw_readl(base + reg);
>  }
>
> -/* Erratum i693 workaround sequence */
> -static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
> -{
> -       int ret = 0;
> -
> -       /* Switch to the internal 60 MHz clock */
> -       ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
> -       if (ret != 0)
> -               ehci_err(ehci, "init_60m_fclk set parent"
> -                       "failed error:%d\n", ret);
> -
> -       ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
> -       if (ret != 0)
> -               ehci_err(ehci, "init_60m_fclk set parent"
> -                       "failed error:%d\n", ret);
> -
> -       clk_enable(usbhost_p1_fck);
> -       clk_enable(usbhost_p2_fck);
> -
> -       /* Wait 1ms and switch back to the external clock */
> -       mdelay(1);
> -       ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
> -       if (ret != 0)
> -               ehci_err(ehci, "xclk60mhsp1_ck set parent"
> -                       "failed error:%d\n", ret);
> -
> -       ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
> -       if (ret != 0)
> -               ehci_err(ehci, "xclk60mhsp2_ck set parent"
> -                       "failed error:%d\n", ret);
> -
> -       clk_disable(usbhost_p1_fck);
> -       clk_disable(usbhost_p2_fck);
> -}
>
>  static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
>  {
> @@ -145,50 +102,6 @@ static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
>        }
>  }
>
> -static int omap_ehci_hub_control(
> -       struct usb_hcd  *hcd,
> -       u16             typeReq,
> -       u16             wValue,
> -       u16             wIndex,
> -       char            *buf,
> -       u16             wLength
> -)
> -{
> -       struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> -       u32 __iomem *status_reg = &ehci->regs->port_status[
> -                               (wIndex & 0xff) - 1];
> -       u32             temp;
> -       unsigned long   flags;
> -       int             retval = 0;
> -
> -       spin_lock_irqsave(&ehci->lock, flags);
> -
> -       if (typeReq == SetPortFeature && wValue == USB_PORT_FEAT_SUSPEND) {
> -               temp = ehci_readl(ehci, status_reg);
> -               if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) {
> -                       retval = -EPIPE;
> -                       goto done;
> -               }
> -
> -               temp &= ~PORT_WKCONN_E;
> -               temp |= PORT_WKDISC_E | PORT_WKOC_E;
> -               ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> -
> -               omap_ehci_erratum_i693(ehci);
> -
> -               set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
> -               goto done;
> -       }
> -
> -       spin_unlock_irqrestore(&ehci->lock, flags);
> -
> -       /* Handle the hub control events here */
> -       return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
> -done:
> -       spin_unlock_irqrestore(&ehci->lock, flags);
> -       return retval;
> -}
> -
>  static void disable_put_regulator(
>                struct ehci_hcd_omap_platform_data *pdata)
>  {
> @@ -353,76 +266,9 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
>        /* root ports should always stay powered */
>        ehci_port_power(omap_ehci, 1);
>
> -       /* get clocks */
> -       utmi_p1_fck = clk_get(dev, "utmi_p1_gfclk");
> -       if (IS_ERR(utmi_p1_fck)) {
> -               ret = PTR_ERR(utmi_p1_fck);
> -               dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
> -               goto err_add_hcd;
> -       }
> -
> -       xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
> -       if (IS_ERR(xclk60mhsp1_ck)) {
> -               ret = PTR_ERR(xclk60mhsp1_ck);
> -               dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
> -               goto err_utmi_p1_fck;
> -       }
> -
> -       utmi_p2_fck = clk_get(dev, "utmi_p2_gfclk");
> -       if (IS_ERR(utmi_p2_fck)) {
> -               ret = PTR_ERR(utmi_p2_fck);
> -               dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
> -               goto err_xclk60mhsp1_ck;
> -       }
> -
> -       xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
> -       if (IS_ERR(xclk60mhsp2_ck)) {
> -               ret = PTR_ERR(xclk60mhsp2_ck);
> -               dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
> -               goto err_utmi_p2_fck;
> -       }
> -
> -       usbhost_p1_fck = clk_get(dev, "usb_host_hs_utmi_p1_clk");
> -       if (IS_ERR(usbhost_p1_fck)) {
> -               ret = PTR_ERR(usbhost_p1_fck);
> -               dev_err(dev, "usbhost_p1_fck failed error:%d\n", ret);
> -               goto err_xclk60mhsp2_ck;
> -       }
> -
> -       usbhost_p2_fck = clk_get(dev, "usb_host_hs_utmi_p2_clk");
> -       if (IS_ERR(usbhost_p2_fck)) {
> -               ret = PTR_ERR(usbhost_p2_fck);
> -               dev_err(dev, "usbhost_p2_fck failed error:%d\n", ret);
> -               goto err_usbhost_p1_fck;
> -       }
> -
> -       init_60m_fclk = clk_get(dev, "init_60m_fclk");
> -       if (IS_ERR(init_60m_fclk)) {
> -               ret = PTR_ERR(init_60m_fclk);
> -               dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
> -               goto err_usbhost_p2_fck;
> -       }
>
>        return 0;
>
> -err_usbhost_p2_fck:
> -       clk_put(usbhost_p2_fck);
> -
> -err_usbhost_p1_fck:
> -       clk_put(usbhost_p1_fck);
> -
> -err_xclk60mhsp2_ck:
> -       clk_put(xclk60mhsp2_ck);
> -
> -err_utmi_p2_fck:
> -       clk_put(utmi_p2_fck);
> -
> -err_xclk60mhsp1_ck:
> -       clk_put(xclk60mhsp1_ck);
> -
> -err_utmi_p1_fck:
> -       clk_put(utmi_p1_fck);
> -
>  err_add_hcd:
>        disable_put_regulator(pdata);
>        pm_runtime_put_sync(dev);
> @@ -452,14 +298,6 @@ static int ehci_hcd_omap_remove(struct platform_device *pdev)
>        iounmap(hcd->regs);
>        usb_put_hcd(hcd);
>
> -       clk_put(utmi_p1_fck);
> -       clk_put(utmi_p2_fck);
> -       clk_put(xclk60mhsp1_ck);
> -       clk_put(xclk60mhsp2_ck);
> -       clk_put(usbhost_p1_fck);
> -       clk_put(usbhost_p2_fck);
> -       clk_put(init_60m_fclk);
> -
>        pm_runtime_put_sync(dev);
>        pm_runtime_disable(dev);
>
> @@ -530,7 +368,7 @@ static const struct hc_driver ehci_omap_hc_driver = {
>         * root hub support
>         */
>        .hub_status_data        = ehci_hub_status_data,
> -       .hub_control            = omap_ehci_hub_control,
> +       .hub_control            = ehci_hub_control,
>        .bus_suspend            = ehci_bus_suspend,
>        .bus_resume             = ehci_bus_resume,
>
> --
> 1.7.9.5
>

hi kevin

here is pm count log on beagle XM with the above patch:

 cat ./debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)


regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
> <keshava_mgowda@ti.com> wrote:
>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>> the usb hub and device detection fails in beagle XM
>> causeing NFS not functional. This affects the core retention too.
>> The same commit logic needs to be revisted adhering to hwmod and
>> device tree framework.
>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>>
>> This patch is validated on BeagleXM with NFS support over
>> usb ethernet and USB mass storage and other device detection.
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>

[...]

>
> hi kevin
>
> here is pm count log on beagle XM with the above patch:

What are you meaning to show by this log?    

This dump shows that neither PER or CORE are hitting retention in idle.
Which sounds to me like you have not enabled UART runtime suspend:

echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms

My test with your patch shows that it fixes the oops during boot, and
doesn't hang during suspend, but that USB host is still preventing CORE
retention during idle (after UART runtime suspend is enabled.)

This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo

Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.

Kevin


>  cat ./debug/pm_debug/count
> usbhost_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
> per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> dss_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> neon_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0
> mpu_pwrdm (ON),OFF:0,RET:1254,INA:0,ON:1255,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
> usbhost_clkdm->usbhost_pwrdm (3)
> sgx_clkdm->sgx_pwrdm (0)
> per_clkdm->per_pwrdm (19)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (1)
> core_l4_clkdm->core_pwrdm (25)
> core_l3_clkdm->core_pwrdm (4)
> d2d_clkdm->core_pwrdm (0)
> iva2_clkdm->iva2_pwrdm (0)
> neon_clkdm->neon_pwrdm (0)
> mpu_clkdm->mpu_pwrdm (0)
> prm_clkdm->wkup_pwrdm (0)
> cm_clkdm->core_pwrdm (0)
>
>
> regards
> keshava
> --
> 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

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>
>> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
>> <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
>>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>>> the usb hub and device detection fails in beagle XM
>>> causeing NFS not functional. This affects the core retention too.
>>> The same commit logic needs to be revisted adhering to hwmod and
>>> device tree framework.
>>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>>>
>>> This patch is validated on BeagleXM with NFS support over
>>> usb ethernet and USB mass storage and other device detection.
>>>
>>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
>
> [...]
>
>>
>> hi kevin
>>
>> here is pm count log on beagle XM with the above patch:
>
> What are you meaning to show by this log?
>
> This dump shows that neither PER or CORE are hitting retention in idle.
> Which sounds to me like you have not enabled UART runtime suspend:
>
> echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>
> My test with your patch shows that it fixes the oops during boot, and
> doesn't hang during suspend, but that USB host is still preventing CORE
> retention during idle (after UART runtime suspend is enabled.)
>
> This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>
> Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>
> Kevin



Hi kevin
       It woks. only the log was wrong. I was using no_console_suspend
in boot args.
i removed it. now I can see the core retention hits with USB host in Beagle XM.
below is the log:

Please press Enter to activate this console.
/ #
/ #
/ # echo mem > /sys/power/state
[   18.730499] PM: Syncing filesystems ... done.
[   18.735076] PM: Preparing system for mem sleep
[   18.777343] Freezing user space processes ... (elapsed 0.02 seconds) done.
[   18.808410] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[   18.816131] PM: Entering mem sleep
[   18.819702] Suspending console(s) (use no_console_suspend to debug)
[   18.832000] usb 1-2.1: usb suspend, wakeup 0
[   18.855285] hub 1-2:1.0: hub_suspend
[   18.855529] usb 1-2: unlink qh256-0001/dec8ca40 start 1 [1/0 us]
[   18.855957] usb 1-2: usb suspend, wakeup 0
[   18.878417] hub 1-0:1.0: hub_suspend
[   18.878479] usb usb1: bus suspend, wakeup 0
[   18.878479] ehci-omap ehci-omap.0: suspend root hub
[   18.991302] PM: suspend of devices complete after 161.865 msecs
[   18.993865] PM: late suspend of devices complete after 2.502 msecs
[   18.998443] PM: noirq suspend of devices complete after 4.547 msecs
[   18.998504] Disabling non-boot CPUs ...
[   19.257965] Successfully put all powerdomains to target state
[   19.260253] PM: noirq resume of devices complete after 2.105 msecs
[   19.263336] PM: early resume of devices complete after 1.739 msecs
[   19.571258] usb usb1: usb resume
[   19.571258] ehci-omap ehci-omap.0: resume root hub after power loss
[   19.614288] hub 1-0:1.0: hub_resume
[   19.614501] hub 1-0:1.0: port 2: status 0000 change 0000
[   19.615020] hub 1-0:1.0: port 2 status 0000.0000 after resume, -19
[   19.615020] usb 1-2: can't resume, status -19
[   19.615020] hub 1-0:1.0: logical disconnect on port 2
[   19.615600] PM: resume of devices complete after 352.111 msecs
[   19.735168] PM: Finishing wakeup.
[   19.739715] hub 1-0:1.0: state 7 ports 3 chg 0004 evt 0000
[   19.745544] hub 1-0:1.0: port 2, status 0000, change 0000, 12 Mb/s
[   19.752105] usb 1-2: USB disconnect, device number 2
[   19.757385] usb 1-2.1: USB disconnect, device number 3
[   19.762817] usb 1-2.1: unregistering device
[   19.767211] usb 1-2.1: unregistering interface 1-2.1:1.0
[   19.783142] Restarting tasks ... done.
/ # [   19.798645] usb 1-2.1: usb_disable_device nuking all URBs
[   19.813323] usb 1-2: unregistering device
[   19.817718] usb 1-2: unregistering interface 1-2:1.0
[   19.841735] usb 1-2: usb_disable_device nuking all URBs

/ # [   22.200866] hub 1-0:1.0: hub_suspend
[   22.204864] usb usb1: bus auto-suspend, wakeup 1
[   22.209838] ehci-omap ehci-omap.0: suspend root hub

/ #
/ #
/ # mkdir /debug
mount -t debugfs debugfs / # mount -t debugfs debugfs /debug
/ #
/ #
/ # echo mem > /sys/power/state
[   74.603454] PM: Syncing filesystems ... done.
[   74.608215] PM: Preparing system for mem sleep
[   74.637695] Freezing user space processes ... (elapsed 0.02 seconds) done.
[   74.661132] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[   74.668853] PM: Entering mem sleep
[   74.672424] Suspending console(s) (use no_console_suspend to debug)
[   74.685516] usb usb1: usb auto-resume
[   74.685546] ehci-omap ehci-omap.0: resume root hub
[   74.762573] hub 1-0:1.0: hub_resume
[   74.762817] hub 1-0:1.0: hub_suspend
[   74.762847] usb usb1: bus suspend, wakeup 0
[   74.762878] ehci-omap ehci-omap.0: suspend root hub
[   74.875061] PM: suspend of devices complete after 192.942 msecs
[   74.877441] PM: late suspend of devices complete after 2.349 msecs
[   74.881591] PM: noirq suspend of devices complete after 4.118 msecs
[   74.881591] Disabling non-boot CPUs ...
[   75.162689] Successfully put all powerdomains to target state
[   75.164886] PM: noirq resume of devices complete after 2.044 msecs
[   75.167785] PM: early resume of devices complete after 1.555 msecs
[   75.476531] usb usb1: usb resume
[   75.476562] ehci-omap ehci-omap.0: resume root hub after power loss
[   75.551544] hub 1-0:1.0: hub_resume
[   75.552032] PM: resume of devices complete after 384.123 msecs
[   75.643096] PM: Finishing wakeup.
[   75.647155] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[   75.657257] Restarting tasks ... done.
/ #
/ # [   77.653442] hub 1-0:1.0: hub_suspend
[   77.657257] usb usb1: bus auto-suspend, wakeup 1
[   77.662200] ehci-omap ehci-omap.0: suspend root hub

/ # cat /debug/pm_debug/co
/debug/pm_debug/core_pwrdm/  /debug/pm_debug/count
/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:565,INA:0,ON:566,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:565,INA:0,ON:566,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:565,INA:0,ON:566,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
/ #
/ #
/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:676,INA:0,ON:677,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:676,INA:0,ON:677,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:676,INA:0,ON:677,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:760,INA:0,ON:761,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:760,INA:0,ON:761,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:760,INA:0,ON:761,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
/ #
/ # echo mem > /sys/power/state
[  136.349517] PM: Syncing filesystems ... done.
[  136.354125] PM: Preparing system for mem sleep
[  136.380157] Freezing user space processes ... (elapsed 0.02 seconds) done.
[  136.411437] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[  136.419158] PM: Entering mem sleep
[  136.422729] Suspending console(s) (use no_console_suspend to debug)
[  136.435882] usb usb1: usb auto-resume
[  136.435913] ehci-omap ehci-omap.0: resume root hub
[  136.512481] hub 1-0:1.0: hub_resume
[  136.512634] hub 1-0:1.0: hub_suspend
[  136.512695] usb usb1: bus suspend, wakeup 0
[  136.512695] ehci-omap ehci-omap.0: suspend root hub
[  136.624847] PM: suspend of devices complete after 192.612 msecs
[  136.627227] PM: late suspend of devices complete after 2.319 msecs
[  136.631378] PM: noirq suspend of devices complete after 4.151 msecs
[  136.631408] Disabling non-boot CPUs ...
[  137.409423] Successfully put all powerdomains to target state
[  137.411590] PM: noirq resume of devices complete after 2.045 msecs
[  137.414489] PM: early resume of devices complete after 1.556 msecs
[  137.723266] usb usb1: usb resume
[  137.723266] ehci-omap ehci-omap.0: resume root hub after power loss
[  137.798187] hub 1-0:1.0: hub_resume
[  137.798583] PM: resume of devices complete after 383.972 msecs
[  137.889617] PM: Finishing wakeup.
[  137.893676] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[  137.903594] Restarting tasks ... done.
/ #
/ #
/ # echo mem > /sys/power/state[  140.259704] hub 1-0:1.0: hub_suspend
[  140.263519] usb usb1: bus auto-suspend, wakeup 1
[  140.268463] ehci-omap ehci-omap.0: suspend root hub
/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:3,INA:0,ON:4,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:905,INA:0,ON:906,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:905,INA:0,ON:906,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:905,INA:0,ON:906,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
/ # echo mem > /sys/power/state
[ 1851.239776] PM: Syncing filesystems ... done.
[ 1851.244506] PM: Preparing system for mem sleep
[ 1851.268096] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 1851.291290] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[ 1851.299011] PM: Entering mem sleep
[ 1851.302581] Suspending console(s) (use no_console_suspend to debug)
[ 1851.315734] usb usb1: usb auto-resume
[ 1851.315734] ehci-omap ehci-omap.0: resume root hub
[ 1851.392547] hub 1-0:1.0: hub_resume
[ 1851.392730] hub 1-0:1.0: hub_suspend
[ 1851.392761] usb usb1: bus suspend, wakeup 0
[ 1851.392791] ehci-omap ehci-omap.0: suspend root hub
[ 1851.504852] PM: suspend of devices complete after 192.961 msecs
[ 1851.507232] PM: late suspend of devices complete after 2.382 msecs
[ 1851.511383] PM: noirq suspend of devices complete after 4.123 msecs
[ 1851.511413] Disabling non-boot CPUs ...
[ 1852.511322] Successfully put all powerdomains to target state
[ 1852.513519] PM: noirq resume of devices complete after 2.046 msecs
[ 1852.516418] PM: early resume of devices complete after 1.588 msecs
[ 1852.825164] usb usb1: usb resume
[ 1852.825164] ehci-omap ehci-omap.0: resume root hub after power loss
[ 1852.900085] hub 1-0:1.0: hub_resume
[ 1852.900482] PM: resume of devices complete after 383.948 msecs
[ 1852.991546] PM: Finishing wakeup.
[ 1852.995574] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[ 1853.005676] Restarting tasks ... done.
/ # cat /debug/pm_debug/count [ 1855.259979] hub 1-0:1.0: hub_suspend
[ 1855.263793] usb usb1: bus auto-suspend, wakeup 1
[ 1855.268707] ehci-omap ehci-omap.0: suspend root hub

usbhost_pwrdm (ON),OFF:0,RET:4,INA:0,ON:5,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:4,INA:0,ON:5,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:4,INA:0,ON:5,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:2805,INA:0,ON:2806,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:2805,INA:0,ON:2806,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:2805,INA:0,ON:2806,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)
/ # echo mem > /sys/power/state
[ 2278.128540] PM: Syncing filesystems ... done.
[ 2278.133117] PM: Preparing system for mem sleep
[ 2278.159027] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 2278.182220] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[ 2278.189941] PM: Entering mem sleep
[ 2278.193511] Suspending console(s) (use no_console_suspend to debug)
[ 2278.206726] usb usb1: usb auto-resume
[ 2278.206756] ehci-omap ehci-omap.0: resume root hub
[ 2278.283477] hub 1-0:1.0: hub_resume
[ 2278.283660] hub 1-0:1.0: hub_suspend
[ 2278.283691] usb usb1: bus suspend, wakeup 0
[ 2278.283721] ehci-omap ehci-omap.0: suspend root hub
[ 2278.395782] PM: suspend of devices complete after 192.952 msecs
[ 2278.398162] PM: late suspend of devices complete after 2.352 msecs
[ 2278.402313] PM: noirq suspend of devices complete after 4.123 msecs
[ 2278.402313] Disabling non-boot CPUs ...
[ 2278.898864] Successfully put all powerdomains to target state
[ 2278.901062] PM: noirq resume of devices complete after 2.046 msecs
[ 2278.903961] PM: early resume of devices complete after 1.557 msecs
[ 2279.212676] usb usb1: usb resume
[ 2279.212676] ehci-omap ehci-omap.0: resume root hub after power loss
[ 2279.287628] hub 1-0:1.0: hub_resume
[ 2279.288024] PM: resume of devices complete after 383.916 msecs
[ 2279.379058] PM: Finishing wakeup.
[ 2279.383087] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[ 2279.393005] Restarting tasks ... done.
/ #
/ #
/ # cat /debug/pm_debug/count [ 2281.756500] hub 1-0:1.0: hub_suspend
[ 2281.760314] usb usb1: bus auto-suspend, wakeup 1
[ 2281.765228] ehci-omap ehci-omap.0: suspend root hub

usbhost_pwrdm (ON),OFF:0,RET:5,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:5,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:5,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:3368,INA:0,ON:3369,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:3368,INA:0,ON:3369,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:3368,INA:0,ON:3369,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (3)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (19)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
core_l4_clkdm->core_pwrdm (25)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)


>> regards
>> keshava
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

Hi,

On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote:
> On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> > "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
> >
> >> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
> >> <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> >>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> >>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> >>> the usb hub and device detection fails in beagle XM
> >>> causeing NFS not functional. This affects the core retention too.
> >>> The same commit logic needs to be revisted adhering to hwmod and
> >>> device tree framework.
> >>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> >>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> >>>
> >>> This patch is validated on BeagleXM with NFS support over
> >>> usb ethernet and USB mass storage and other device detection.
> >>>
> >>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> >
> > [...]
> >
> >>
> >> hi kevin
> >>
> >> here is pm count log on beagle XM with the above patch:
> >
> > What are you meaning to show by this log?
> >
> > This dump shows that neither PER or CORE are hitting retention in idle.
> > Which sounds to me like you have not enabled UART runtime suspend:
> >
> > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
> > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
> > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
> > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
> >
> > My test with your patch shows that it fixes the oops during boot, and
> > doesn't hang during suspend, but that USB host is still preventing CORE
> > retention during idle (after UART runtime suspend is enabled.)
> >
> > This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
> >
> > Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
> >
> > Kevin
> 
> 
> 
> Hi kevin
>        It woks. only the log was wrong. I was using no_console_suspend
> in boot args.
> i removed it. now I can see the core retention hits with USB host in Beagle XM.
> below is the log:

the fact is that we can't really survive without that workaround. Kevin,
Paul what are the suggestions here ? We _MUST_ reparent the clock at
that specific location as a HW workaround.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:

> Hi,
>
> On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote:
>> On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>> > "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>> >
>> >> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
>> >> <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
>> >>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>> >>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>> >>> the usb hub and device detection fails in beagle XM
>> >>> causeing NFS not functional. This affects the core retention too.
>> >>> The same commit logic needs to be revisted adhering to hwmod and
>> >>> device tree framework.
>> >>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>> >>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>> >>>
>> >>> This patch is validated on BeagleXM with NFS support over
>> >>> usb ethernet and USB mass storage and other device detection.
>> >>>
>> >>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
>> >
>> > [...]
>> >
>> >>
>> >> hi kevin
>> >>
>> >> here is pm count log on beagle XM with the above patch:
>> >
>> > What are you meaning to show by this log?
>> >
>> > This dump shows that neither PER or CORE are hitting retention in idle.
>> > Which sounds to me like you have not enabled UART runtime suspend:
>> >
>> > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>> > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>> > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>> > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>> >
>> > My test with your patch shows that it fixes the oops during boot, and
>> > doesn't hang during suspend, but that USB host is still preventing CORE
>> > retention during idle (after UART runtime suspend is enabled.)
>> >
>> > This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>> >
>> > Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>> >
>> > Kevin
>> 
>> 
>> 
>> Hi kevin
>>        It woks. only the log was wrong. I was using no_console_suspend
>> in boot args.
>> i removed it. now I can see the core retention hits with USB host in Beagle XM.
>> below is the log:
>
> the fact is that we can't really survive without that workaround. Kevin,

I don't know what workaround you're talking about.    Are you talking
about the revert proposed in $SUBJECT patch?

I don't have a problem with that revert.  The problem I have is that it
does not fix the problem I initially reported: USB host prevents CORE
retention in *idle*.

Kevin

> Paul what are the suggestions here ? We _MUST_ reparent the clock at
> that specific location as a HW workaround.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Russ Dill]

On Fri, Jun 22, 2012 at 7:14 AM, Kevin Hilman <khilman@ti.com> wrote:
> Felipe Balbi <balbi@ti.com> writes:
>
>> Hi,
>>
>> On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote:
>>> On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> > "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>> >
>>> >> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
>>> >> <keshava_mgowda@ti.com> wrote:
>>> >>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>>> >>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>>> >>> the usb hub and device detection fails in beagle XM
>>> >>> causeing NFS not functional. This affects the core retention too.
>>> >>> The same commit logic needs to be revisted adhering to hwmod and
>>> >>> device tree framework.
>>> >>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>>> >>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>>> >>>
>>> >>> This patch is validated on BeagleXM with NFS support over
>>> >>> usb ethernet and USB mass storage and other device detection.
>>> >>>
>>> >>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
>>> >
>>> > [...]
>>> >
>>> >>
>>> >> hi kevin
>>> >>
>>> >> here is pm count log on beagle XM with the above patch:
>>> >
>>> > What are you meaning to show by this log?
>>> >
>>> > This dump shows that neither PER or CORE are hitting retention in idle.
>>> > Which sounds to me like you have not enabled UART runtime suspend:
>>> >
>>> > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>>> > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>>> > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>>> > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>>> >
>>> > My test with your patch shows that it fixes the oops during boot, and
>>> > doesn't hang during suspend, but that USB host is still preventing CORE
>>> > retention during idle (after UART runtime suspend is enabled.)
>>> >
>>> > This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>>> >
>>> > Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>>> >
>>> > Kevin
>>>
>>>
>>>
>>> Hi kevin
>>>        It woks. only the log was wrong. I was using no_console_suspend
>>> in boot args.
>>> i removed it. now I can see the core retention hits with USB host in Beagle XM.
>>> below is the log:
>>
>> the fact is that we can't really survive without that workaround. Kevin,
>
> I don't know what workaround you're talking about.    Are you talking
> about the revert proposed in $SUBJECT patch?
>
> I don't have a problem with that revert.  The problem I have is that it
> does not fix the problem I initially reported: USB host prevents CORE
> retention in *idle*.

I already have a pair of patches posted to linux-omap and linux that
fixes the oops on boot caused by the i693 errata patch. The first
fixes the bad error path that causes the oops, the second allows the
dummy clocks on omap3xxx to be grabbed by the ehci-host driver as is
being done with real clocks on the omap44xx.
--
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

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Fri, Jun 22, 2012 at 8:33 PM, Russ Dill <russ.dill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jun 22, 2012 at 7:14 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>
>>> Hi,
>>>
>>> On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote:
>>>> On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>>>> > "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>>>> >
>>>> >> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
>>>> >> <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
>>>> >>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>>>> >>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>>>> >>> the usb hub and device detection fails in beagle XM
>>>> >>> causeing NFS not functional. This affects the core retention too.
>>>> >>> The same commit logic needs to be revisted adhering to hwmod and
>>>> >>> device tree framework.
>>>> >>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>>>> >>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>>>> >>>
>>>> >>> This patch is validated on BeagleXM with NFS support over
>>>> >>> usb ethernet and USB mass storage and other device detection.
>>>> >>>
>>>> >>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
>>>> >
>>>> > [...]
>>>> >
>>>> >>
>>>> >> hi kevin
>>>> >>
>>>> >> here is pm count log on beagle XM with the above patch:
>>>> >
>>>> > What are you meaning to show by this log?
>>>> >
>>>> > This dump shows that neither PER or CORE are hitting retention in idle.
>>>> > Which sounds to me like you have not enabled UART runtime suspend:
>>>> >
>>>> > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>>>> > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>>>> > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>>>> > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>>>> >
>>>> > My test with your patch shows that it fixes the oops during boot, and
>>>> > doesn't hang during suspend, but that USB host is still preventing CORE
>>>> > retention during idle (after UART runtime suspend is enabled.)
>>>> >
>>>> > This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>>>> >
>>>> > Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>>>> >
>>>> > Kevin
>>>>
>>>>
>>>>
>>>> Hi kevin
>>>>        It woks. only the log was wrong. I was using no_console_suspend
>>>> in boot args.
>>>> i removed it. now I can see the core retention hits with USB host in Beagle XM.
>>>> below is the log:
>>>
>>> the fact is that we can't really survive without that workaround. Kevin,
>>
>> I don't know what workaround you're talking about.    Are you talking
>> about the revert proposed in $SUBJECT patch?
>>
>> I don't have a problem with that revert.  The problem I have is that it
>> does not fix the problem I initially reported: USB host prevents CORE
>> retention in *idle*.
>
> I already have a pair of patches posted to linux-omap and linux that
> fixes the oops on boot caused by the i693 errata patch. The first
> fixes the bad error path that causes the oops, the second allows the
> dummy clocks on omap3xxx to be grabbed by the ehci-host driver as is
> being done with real clocks on the omap44xx.

I request please resend the patches !
 cc me (keshava_mgowda-l0cyMroinI0@public.gmane.org) in all your patches.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

Hi,

On Fri, Jun 22, 2012 at 07:14:32AM -0700, Kevin Hilman wrote:
> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
> 
> > Hi,
> >
> > On Fri, Jun 22, 2012 at 01:00:39PM +0530, Munegowda, Keshava wrote:
> >> On Fri, Jun 22, 2012 at 12:32 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> >> > "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
> >> >
> >> >> On Thu, Jun 21, 2012 at 7:12 PM, Keshava Munegowda
> >> >> <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> >> >>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> >> >>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> >> >>> the usb hub and device detection fails in beagle XM
> >> >>> causeing NFS not functional. This affects the core retention too.
> >> >>> The same commit logic needs to be revisted adhering to hwmod and
> >> >>> device tree framework.
> >> >>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> >> >>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> >> >>>
> >> >>> This patch is validated on BeagleXM with NFS support over
> >> >>> usb ethernet and USB mass storage and other device detection.
> >> >>>
> >> >>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> >> >
> >> > [...]
> >> >
> >> >>
> >> >> hi kevin
> >> >>
> >> >> here is pm count log on beagle XM with the above patch:
> >> >
> >> > What are you meaning to show by this log?
> >> >
> >> > This dump shows that neither PER or CORE are hitting retention in idle.
> >> > Which sounds to me like you have not enabled UART runtime suspend:
> >> >
> >> > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
> >> > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
> >> > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
> >> > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
> >> >
> >> > My test with your patch shows that it fixes the oops during boot, and
> >> > doesn't hang during suspend, but that USB host is still preventing CORE
> >> > retention during idle (after UART runtime suspend is enabled.)
> >> >
> >> > This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
> >> >
> >> > Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
> >> >
> >> > Kevin
> >> 
> >> 
> >> 
> >> Hi kevin
> >>        It woks. only the log was wrong. I was using no_console_suspend
> >> in boot args.
> >> i removed it. now I can see the core retention hits with USB host in Beagle XM.
> >> below is the log:
> >
> > the fact is that we can't really survive without that workaround. Kevin,
> 
> I don't know what workaround you're talking about.    Are you talking
> about the revert proposed in $SUBJECT patch?
> 
> I don't have a problem with that revert.  The problem I have is that it
> does not fix the problem I initially reported: USB host prevents CORE
> retention in *idle*.

Keshava is reverting a fix for a HW errata. I can't accept it as it will
cause regressions. Granted, regression by regression, there's no change,
but I simply can't knowingly cause a regression to the driver just to
have PM working. We need a real fix for this issue.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

Felipe Balbi <balbi@ti.com> writes:

[...]

> Keshava is reverting a fix for a HW errata. I can't accept it as it will
> cause regressions. Granted, regression by regression, there's no change,
> but I simply can't knowingly cause a regression to the driver just to
> have PM working. We need a real fix for this issue.

Sure, as long as there is a fix in this -rc cycle.

This driver intoduced changes in v3.5 that break PM for the whole SoC
(by preventing CORE retention.)  These changes were clearly not tested
with PM.

If you cannot fix this during the -rc cycle, then you need to revert the
driver PM changes that broke PM for the *whole* SoC.

Kevin

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

Felipe, Keshava,

Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:

> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>
> [...]
>
>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>> cause regressions. Granted, regression by regression, there's no change,
>> but I simply can't knowingly cause a regression to the driver just to
>> have PM working. We need a real fix for this issue.
>
> Sure, as long as there is a fix in this -rc cycle.
>
> This driver intoduced changes in v3.5 that break PM for the whole SoC
> (by preventing CORE retention.)  These changes were clearly not tested
> with PM.
>
> If you cannot fix this during the -rc cycle, then you need to revert the
> driver PM changes that broke PM for the *whole* SoC.

What's the status of this regression?

This is still broken in v3.5-rc and is preventing CORE retention for the
*whole* SoC.

Please fix this, either with a proper fix, or a revert for 3.5-rc.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Russ Dill]

On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> Felipe, Keshava,
>
> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>
>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>
>> [...]
>>
>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>> cause regressions. Granted, regression by regression, there's no change,
>>> but I simply can't knowingly cause a regression to the driver just to
>>> have PM working. We need a real fix for this issue.
>>
>> Sure, as long as there is a fix in this -rc cycle.
>>
>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>> (by preventing CORE retention.)  These changes were clearly not tested
>> with PM.
>>
>> If you cannot fix this during the -rc cycle, then you need to revert the
>> driver PM changes that broke PM for the *whole* SoC.
>
> What's the status of this regression?
>
> This is still broken in v3.5-rc and is preventing CORE retention for the
> *whole* SoC.
>
> Please fix this, either with a proper fix, or a revert for 3.5-rc.

Were you able to merge my patches that at least fix the oops on boot
and get EHCI working again on omap-3xxx?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

Russ Dill <russ.dill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>> Felipe, Keshava,
>>
>> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>>
>>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>>
>>> [...]
>>>
>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>>> cause regressions. Granted, regression by regression, there's no change,
>>>> but I simply can't knowingly cause a regression to the driver just to
>>>> have PM working. We need a real fix for this issue.
>>>
>>> Sure, as long as there is a fix in this -rc cycle.
>>>
>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>>> (by preventing CORE retention.)  These changes were clearly not tested
>>> with PM.
>>>
>>> If you cannot fix this during the -rc cycle, then you need to revert the
>>> driver PM changes that broke PM for the *whole* SoC.
>>
>> What's the status of this regression?
>>
>> This is still broken in v3.5-rc and is preventing CORE retention for the
>> *whole* SoC.
>>
>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>
> Were you able to merge my patches that at least fix the oops on boot
> and get EHCI working again on omap-3xxx?

I didn't try your patches specifically, but those are not the problems
I'm most worried about.  

I'm mostly worried about the fact that when EHCI is enabled (and
working), it prevents the CORE powerdomain from hitting retention in
idle, and thus prevents the whole chip from hitting retention in idle.

I'm also worried that the owners of this code are running out of time to
fix these several serious regresions for v3.5.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Samuel Ortiz]

Hi Kevin,

On Mon, Jul 02, 2012 at 10:55:39AM -0700, Kevin Hilman wrote:
> I'm also worried that the owners of this code are running out of time to
> fix these several serious regresions for v3.5.
FYI, I only have one omap-usb fix queued for 3.5 in my for-linus branch, see
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=shortlog;h=refs/heads/for-linus

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:

> Felipe, Keshava,
>
> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>
>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>
>> [...]
>>
>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>> cause regressions. Granted, regression by regression, there's no change,
>>> but I simply can't knowingly cause a regression to the driver just to
>>> have PM working. We need a real fix for this issue.
>>
>> Sure, as long as there is a fix in this -rc cycle.
>>
>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>> (by preventing CORE retention.)  These changes were clearly not tested
>> with PM.
>>
>> If you cannot fix this during the -rc cycle, then you need to revert the
>> driver PM changes that broke PM for the *whole* SoC.
>
> What's the status of this regression?
>
> This is still broken in v3.5-rc and is preventing CORE retention for the
> *whole* SoC.
>
> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>

BTW, a related issue with this driver (but not sure it's a regression)
is that USB ethernet does not seem to survive a suspend/resume.

If I'm using a NFS rootfs, after suspend/resume, the NFS servers stops
responding, and I get these errors:

  nfs: server X.X.X.X not responding, still trying

The result is that I have to use an initramfs on BB-xM in order to do
suspend/resume testing.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Tue, Jul 3, 2012 at 5:44 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> Felipe, Keshava,
>>
>> Kevin Hilman <khilman@ti.com> writes:
>>
>>> Felipe Balbi <balbi@ti.com> writes:
>>>
>>> [...]
>>>
>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>>> cause regressions. Granted, regression by regression, there's no change,
>>>> but I simply can't knowingly cause a regression to the driver just to
>>>> have PM working. We need a real fix for this issue.
>>>
>>> Sure, as long as there is a fix in this -rc cycle.
>>>
>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>>> (by preventing CORE retention.)  These changes were clearly not tested
>>> with PM.
>>>
>>> If you cannot fix this during the -rc cycle, then you need to revert the
>>> driver PM changes that broke PM for the *whole* SoC.
>>
>> What's the status of this regression?
>>
>> This is still broken in v3.5-rc and is preventing CORE retention for the
>> *whole* SoC.
>>
>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>>
>
> BTW, a related issue with this driver (but not sure it's a regression)
> is that USB ethernet does not seem to survive a suspend/resume.
>
> If I'm using a NFS rootfs, after suspend/resume, the NFS servers stops
> responding, and I get these errors:
>
>   nfs: server X.X.X.X not responding, still trying

This issue because of two issues:

1. The phy goes to bad state and ehci ports goes out the suspend
                    Fix was made by resetting the phy and re-power the
ehci ports; but Alan has commented on this.
                 it stil requires a reworks
2. The usb-serial driver does not have reset-resume, so it gets the
different ip address but NFS wont be functional
                     nothing can be done in the ehci driver,
debugging is requried at usb serial driver.

regards
keshava

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> Felipe, Keshava,
>
> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>
>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>
>> [...]
>>
>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>> cause regressions. Granted, regression by regression, there's no change,
>>> but I simply can't knowingly cause a regression to the driver just to
>>> have PM working. We need a real fix for this issue.
>>
>> Sure, as long as there is a fix in this -rc cycle.
>>
>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>> (by preventing CORE retention.)  These changes were clearly not tested
>> with PM.
>>
>> If you cannot fix this during the -rc cycle, then you need to revert the
>> driver PM changes that broke PM for the *whole* SoC.
>
> What's the status of this regression?
>
> This is still broken in v3.5-rc and is preventing CORE retention for the
> *whole* SoC.
>
> Please fix this, either with a proper fix, or a revert for 3.5-rc.


The proper fix for this is implement ion of ehci remote wakeup through
I/O chain handler; it takes time.
As Felipe also mentioned,  This patch is OK for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
<keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>> Felipe, Keshava,
>>
>> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>>
>>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>>
>>> [...]
>>>
>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>>> cause regressions. Granted, regression by regression, there's no change,
>>>> but I simply can't knowingly cause a regression to the driver just to
>>>> have PM working. We need a real fix for this issue.
>>>
>>> Sure, as long as there is a fix in this -rc cycle.
>>>
>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>>> (by preventing CORE retention.)  These changes were clearly not tested
>>> with PM.
>>>
>>> If you cannot fix this during the -rc cycle, then you need to revert the
>>> driver PM changes that broke PM for the *whole* SoC.
>>
>> What's the status of this regression?
>>
>> This is still broken in v3.5-rc and is preventing CORE retention for the
>> *whole* SoC.
>>
>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>
>
> The proper fix for this is implement ion of ehci remote wakeup through
> I/O chain handler; it takes time.
> As Felipe also mentioned,  This patch is OK for now.

Sorry, Felipe still insist not to revert this patch, but to change
this patch requires quite more changes in the usbhs core
and we need to see the how the hub control changes need to be brought
in to usbhs core. so , reverting is the
best solution to time being.

Its observed that ehci was enabled after linux kernal version 3.3 ;
before that even though driver was there
the ehci deriver was disabled by defaults; and it is expected the
people who want to use NFS then can enable it
explicitly.

so,  the solution is

1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
suspend/resume crash
2. Disable the ehci driver to make the pm work in idle case ;
              This configuration should exist till the ehci remote
wakeup implementation completes.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
> <keshava_mgowda@ti.com> wrote:
>> On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman@ti.com> wrote:
>>> Felipe, Keshava,
>>>
>>> Kevin Hilman <khilman@ti.com> writes:
>>>
>>>> Felipe Balbi <balbi@ti.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>>>> cause regressions. Granted, regression by regression, there's no change,
>>>>> but I simply can't knowingly cause a regression to the driver just to
>>>>> have PM working. We need a real fix for this issue.
>>>>
>>>> Sure, as long as there is a fix in this -rc cycle.
>>>>
>>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>>>> (by preventing CORE retention.)  These changes were clearly not tested
>>>> with PM.
>>>>
>>>> If you cannot fix this during the -rc cycle, then you need to revert the
>>>> driver PM changes that broke PM for the *whole* SoC.
>>>
>>> What's the status of this regression?
>>>
>>> This is still broken in v3.5-rc and is preventing CORE retention for the
>>> *whole* SoC.
>>>
>>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>>
>>
>> The proper fix for this is implement ion of ehci remote wakeup through
>> I/O chain handler; it takes time.
>> As Felipe also mentioned,  This patch is OK for now.
>
> Sorry, Felipe still insist not to revert this patch, but to change
> this patch requires quite more changes in the usbhs core
> and we need to see the how the hub control changes need to be brought
> in to usbhs core. so , reverting is the
> best solution to time being.
>
> Its observed that ehci was enabled after linux kernal version 3.3 ;
> before that even though driver was there
> the ehci deriver was disabled by defaults; and it is expected the
> people who want to use NFS then can enable it
> explicitly.
>
> so,  the solution is
>
> 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
> suspend/resume crash

Or, use the patches from Russ Dill where were more targetted fixes.
Either way, I'm OK with that.

> 2. Disable the ehci driver to make the pm work in idle case ;
>               This configuration should exist till the ehci remote
> wakeup implementation completes.

Yes.  Please disabled it by default.

Until PM in this driver can work without breaking PM for the whole SoC,
it should remain disabled.

Please queue up all of these fixes ASAP for the v3.5

Kevin

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Samuel Ortiz]

Hi Kevin, Keshava,

On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote:
> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
> 
> > On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
> > <keshava_mgowda@ti.com> wrote:
> >> On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman@ti.com> wrote:
> >>> Felipe, Keshava,
> >>>
> >>> Kevin Hilman <khilman@ti.com> writes:
> >>>
> >>>> Felipe Balbi <balbi@ti.com> writes:
> >>>>
> >>>> [...]
> >>>>
> >>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
> >>>>> cause regressions. Granted, regression by regression, there's no change,
> >>>>> but I simply can't knowingly cause a regression to the driver just to
> >>>>> have PM working. We need a real fix for this issue.
> >>>>
> >>>> Sure, as long as there is a fix in this -rc cycle.
> >>>>
> >>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
> >>>> (by preventing CORE retention.)  These changes were clearly not tested
> >>>> with PM.
> >>>>
> >>>> If you cannot fix this during the -rc cycle, then you need to revert the
> >>>> driver PM changes that broke PM for the *whole* SoC.
> >>>
> >>> What's the status of this regression?
> >>>
> >>> This is still broken in v3.5-rc and is preventing CORE retention for the
> >>> *whole* SoC.
> >>>
> >>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
> >>
> >>
> >> The proper fix for this is implement ion of ehci remote wakeup through
> >> I/O chain handler; it takes time.
> >> As Felipe also mentioned,  This patch is OK for now.
> >
> > Sorry, Felipe still insist not to revert this patch, but to change
> > this patch requires quite more changes in the usbhs core
> > and we need to see the how the hub control changes need to be brought
> > in to usbhs core. so , reverting is the
> > best solution to time being.
> >
> > Its observed that ehci was enabled after linux kernal version 3.3 ;
> > before that even though driver was there
> > the ehci deriver was disabled by defaults; and it is expected the
> > people who want to use NFS then can enable it
> > explicitly.
> >
> > so,  the solution is
> >
> > 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
> > suspend/resume crash
> 
> Or, use the patches from Russ Dill where were more targetted fixes.
> Either way, I'm OK with that.
Keshava, I'll wait for your decision here to know which patch you want me to
take.



> > 2. Disable the ehci driver to make the pm work in idle case ;
> >               This configuration should exist till the ehci remote
> > wakeup implementation completes.
> 
> Yes.  Please disabled it by default.
> 
> Until PM in this driver can work without breaking PM for the whole SoC,
> it should remain disabled.
So, I should expect another patch here as well.
FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus
tomorrow, but I'll wait for you. Hopefully I should be able to send it on
Monday.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Kevin, Keshava,
>
> On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote:
>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>
>> > On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
>> > <keshava_mgowda@ti.com> wrote:
>> >> On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman@ti.com> wrote:
>> >>> Felipe, Keshava,
>> >>>
>> >>> Kevin Hilman <khilman@ti.com> writes:
>> >>>
>> >>>> Felipe Balbi <balbi@ti.com> writes:
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>> >>>>> cause regressions. Granted, regression by regression, there's no change,
>> >>>>> but I simply can't knowingly cause a regression to the driver just to
>> >>>>> have PM working. We need a real fix for this issue.
>> >>>>
>> >>>> Sure, as long as there is a fix in this -rc cycle.
>> >>>>
>> >>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>> >>>> (by preventing CORE retention.)  These changes were clearly not tested
>> >>>> with PM.
>> >>>>
>> >>>> If you cannot fix this during the -rc cycle, then you need to revert the
>> >>>> driver PM changes that broke PM for the *whole* SoC.
>> >>>
>> >>> What's the status of this regression?
>> >>>
>> >>> This is still broken in v3.5-rc and is preventing CORE retention for the
>> >>> *whole* SoC.
>> >>>
>> >>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>> >>
>> >>
>> >> The proper fix for this is implement ion of ehci remote wakeup through
>> >> I/O chain handler; it takes time.
>> >> As Felipe also mentioned,  This patch is OK for now.
>> >
>> > Sorry, Felipe still insist not to revert this patch, but to change
>> > this patch requires quite more changes in the usbhs core
>> > and we need to see the how the hub control changes need to be brought
>> > in to usbhs core. so , reverting is the
>> > best solution to time being.
>> >
>> > Its observed that ehci was enabled after linux kernal version 3.3 ;
>> > before that even though driver was there
>> > the ehci deriver was disabled by defaults; and it is expected the
>> > people who want to use NFS then can enable it
>> > explicitly.
>> >
>> > so,  the solution is
>> >
>> > 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
>> > suspend/resume crash
>>
>> Or, use the patches from Russ Dill where were more targetted fixes.
>> Either way, I'm OK with that.
> Keshava, I'll wait for your decision here to know which patch you want me to
> take.
>
>
>
>> > 2. Disable the ehci driver to make the pm work in idle case ;
>> >               This configuration should exist till the ehci remote
>> > wakeup implementation completes.
>>
>> Yes.  Please disabled it by default.
>>
>> Until PM in this driver can work without breaking PM for the whole SoC,
>> it should remain disabled.
> So, I should expect another patch here as well.
> FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus
> tomorrow, but I'll wait for you. Hopefully I should be able to send it on
> Monday.
>
> Cheers,
> Samuel.

Thanks Samuel

I will send the patches today.

regards
keshava

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 3:30 PM, Munegowda, Keshava
<keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> Hi Kevin, Keshava,
>>
>> On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote:
>>> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>>>
>>> > On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
>>> > <keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
>>> >> On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>>> >>> Felipe, Keshava,
>>> >>>
>>> >>> Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> writes:
>>> >>>
>>> >>>> Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> writes:
>>> >>>>
>>> >>>> [...]
>>> >>>>
>>> >>>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will
>>> >>>>> cause regressions. Granted, regression by regression, there's no change,
>>> >>>>> but I simply can't knowingly cause a regression to the driver just to
>>> >>>>> have PM working. We need a real fix for this issue.
>>> >>>>
>>> >>>> Sure, as long as there is a fix in this -rc cycle.
>>> >>>>
>>> >>>> This driver intoduced changes in v3.5 that break PM for the whole SoC
>>> >>>> (by preventing CORE retention.)  These changes were clearly not tested
>>> >>>> with PM.
>>> >>>>
>>> >>>> If you cannot fix this during the -rc cycle, then you need to revert the
>>> >>>> driver PM changes that broke PM for the *whole* SoC.
>>> >>>
>>> >>> What's the status of this regression?
>>> >>>
>>> >>> This is still broken in v3.5-rc and is preventing CORE retention for the
>>> >>> *whole* SoC.
>>> >>>
>>> >>> Please fix this, either with a proper fix, or a revert for 3.5-rc.
>>> >>
>>> >>
>>> >> The proper fix for this is implement ion of ehci remote wakeup through
>>> >> I/O chain handler; it takes time.
>>> >> As Felipe also mentioned,  This patch is OK for now.
>>> >
>>> > Sorry, Felipe still insist not to revert this patch, but to change
>>> > this patch requires quite more changes in the usbhs core
>>> > and we need to see the how the hub control changes need to be brought
>>> > in to usbhs core. so , reverting is the
>>> > best solution to time being.
>>> >
>>> > Its observed that ehci was enabled after linux kernal version 3.3 ;
>>> > before that even though driver was there
>>> > the ehci deriver was disabled by defaults; and it is expected the
>>> > people who want to use NFS then can enable it
>>> > explicitly.
>>> >
>>> > so,  the solution is
>>> >
>>> > 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
>>> > suspend/resume crash
>>>
>>> Or, use the patches from Russ Dill where were more targetted fixes.
>>> Either way, I'm OK with that.
>> Keshava, I'll wait for your decision here to know which patch you want me to
>> take.
>>
>>
>>
>>> > 2. Disable the ehci driver to make the pm work in idle case ;
>>> >               This configuration should exist till the ehci remote
>>> > wakeup implementation completes.
>>>
>>> Yes.  Please disabled it by default.
>>>
>>> Until PM in this driver can work without breaking PM for the whole SoC,
>>> it should remain disabled.
>> So, I should expect another patch here as well.
>> FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus
>> tomorrow, but I'll wait for you. Hopefully I should be able to send it on
>> Monday.
>>
>> Cheers,
>> Samuel.
>
> Thanks Samuel
>
> I will send the patches today.
>
> regards
> keshava

Samuel
          I have sent that patch to disable the ehci in
omap2plus_defconfig; after merging that
please merge this patch too. This will fix the crashes in during boot
with NFS in beagleXM

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Samuel Ortiz]

Hi Keshava, Kevin,

On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
> Samuel
>           I have sent that patch to disable the ehci in
> omap2plus_defconfig; after merging that
> please merge this patch too. This will fix the crashes in during boot
> with NFS in beagleXM
I'm going to apply and push this patch for 3.5, and the defconfig patch can be
pushed through Tony's tree.
Kevin, could you please ACK it ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> Hi Keshava, Kevin,
>
> On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
>> Samuel
>>           I have sent that patch to disable the ehci in
>> omap2plus_defconfig; after merging that
>> please merge this patch too. This will fix the crashes in during boot
>> with NFS in beagleXM
> I'm going to apply and push this patch for 3.5, and the defconfig patch can be
> pushed through Tony's tree.
> Kevin, could you please ACK it ?
>
> Cheers,
> Samuel.
>

Thanks Samuel

Kevin,
    need your ack for this.
The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)",
is handling the clocks in ehci driver which is not correct,
it will be through the usb host driver ( /mfd/omap-usb_host.c )  exporting
APIs to ehci driver to handler the port clocks.

for now, this patch is necessary to remove the
 commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)",

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
>> Hi Keshava, Kevin,
>>
>> On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
>>> Samuel
>>>           I have sent that patch to disable the ehci in
>>> omap2plus_defconfig; after merging that
>>> please merge this patch too. This will fix the crashes in during boot
>>> with NFS in beagleXM
>> I'm going to apply and push this patch for 3.5, and the defconfig patch can be
>> pushed through Tony's tree.
>> Kevin, could you please ACK it ?
>>
>> Cheers,
>> Samuel.
>>
>
> Thanks Samuel
>
> Kevin,
>     need your ack for this.

You never answered earlier questions from myself or Russ Dill about the
more targetted patches from Russ:

   ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
   Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes

Also, your current $SUBJECT patch is large and not well
described. e.g. what is "not correct" and why.  Why does it fix the
problems mentioned?  The original changelog mentions the "core retention
issue" but this patch does nothing to address that.  If you want an Ack
from me, especially because I'm not an expert in this IP, you'll have to
describe things in a way that I can understand.

IMO, at this point of the dev cycle (trying to stabilize v3.5), the full
cleanup/fix of this feature will need to be done for v3.6.  For v3.5, I
think the two patches from Russ Dill should be merged.   They are
targetted fixes and very well described.

Kevin

> The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> "Fix OMAP EHCI suspend/resume failure (i693)",
> is handling the clocks in ehci driver which is not correct,
> it will be through the usb host driver ( /mfd/omap-usb_host.c )  exporting
> APIs to ehci driver to handler the port clocks.
>
> for now, this patch is necessary to remove the
>  commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> "Fix OMAP EHCI suspend/resume failure (i693)",
>
> regards
> keshava
> --
> 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

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>
>> On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>> Hi Keshava, Kevin,
>>>
>>> On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
>>>> Samuel
>>>>           I have sent that patch to disable the ehci in
>>>> omap2plus_defconfig; after merging that
>>>> please merge this patch too. This will fix the crashes in during boot
>>>> with NFS in beagleXM
>>> I'm going to apply and push this patch for 3.5, and the defconfig patch can be
>>> pushed through Tony's tree.
>>> Kevin, could you please ACK it ?
>>>
>>> Cheers,
>>> Samuel.
>>>
>>
>> Thanks Samuel
>>
>> Kevin,
>>     need your ack for this.
>
> You never answered earlier questions from myself or Russ Dill about the
> more targetted patches from Russ:
>
>    ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
>    Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes
>
> Also, your current $SUBJECT patch is large and not well
> described. e.g. what is "not correct" and why.  Why does it fix the
> problems mentioned?  The original changelog mentions the "core retention
> issue" but this patch does nothing to address that.  If you want an Ack
> from me, especially because I'm not an expert in this IP, you'll have to
> describe things in a way that I can understand.
>
> IMO, at this point of the dev cycle (trying to stabilize v3.5), the full
> cleanup/fix of this feature will need to be done for v3.6.  For v3.5, I
> think the two patches from Russ Dill should be merged.   They are
> targetted fixes and very well described.
>
> Kevin
>


Hi Kevin
        The usb2 host of omap3/4/5 silicons has the following ips

1. UHH   (  /drivers/mfd/omap-usb-host.c ) -- platform driver
2. TLL    ( /drivers/mfd/omap-usb-host.c )
3. ehci    ( /drivers/usb/host/ehci-omap.c)  - platform driver
4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers

The 3 platform drivers exists to make the ehci/ohci functional.

The  UHH-TLL or usb host core driver is the parent platform driver of
ehci and ohci.
This parent driver doe the clock enable/disable which common for both
ehci and ohci.
takes care of common port setting and clocks during suspend and resume
and ensures
that there is no overwrites by ehci and ohci platform drivers.

The commit id  354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)" was handling the clocks in
the ehci driver it self, instead it should be handled by usb host core
driver  as per above
explanation. so, the UHH-TLL Driver should handle the changes done by
354ab8567ae3107a8cbe7228c3181990ba598aac.


hence this patch removes the changed done by the commit id
354ab8567ae3107a8cbe7228c3181990ba598aac

suppose if this patch is not included, then it will cause the
following two problems

1.  crash during the system boot
                       - observed in beagle xm , with NFS file system
                                           the Ethernet is through
ehci driver , since the ehci ports clocks are not handled properly
                         by this commit id
354ab8567ae3107a8cbe7228c3181990ba598aac,  it leads to crash

2. crash during suspend/resume
                  - observed in beagle xm with ram fs
                                     if the ehci is driver is included
and if it tries to suspend it leads to crash

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Thu, Jul 12, 2012 at 12:11 PM, Munegowda, Keshava
<keshava_mgowda-l0cyMroinI0@public.gmane.org> wrote:
> On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>>
>>> On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>>> Hi Keshava, Kevin,
>>>>
>>>> On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
>>>>> Samuel
>>>>>           I have sent that patch to disable the ehci in
>>>>> omap2plus_defconfig; after merging that
>>>>> please merge this patch too. This will fix the crashes in during boot
>>>>> with NFS in beagleXM
>>>> I'm going to apply and push this patch for 3.5, and the defconfig patch can be
>>>> pushed through Tony's tree.
>>>> Kevin, could you please ACK it ?
>>>>
>>>> Cheers,
>>>> Samuel.
>>>>
>>>
>>> Thanks Samuel
>>>
>>> Kevin,
>>>     need your ack for this.
>>
>> You never answered earlier questions from myself or Russ Dill about the
>> more targetted patches from Russ:
>>
>>    ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path
>>    Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes
>>
>> Also, your current $SUBJECT patch is large and not well
>> described. e.g. what is "not correct" and why.  Why does it fix the
>> problems mentioned?  The original changelog mentions the "core retention
>> issue" but this patch does nothing to address that.  If you want an Ack
>> from me, especially because I'm not an expert in this IP, you'll have to
>> describe things in a way that I can understand.
>>
>> IMO, at this point of the dev cycle (trying to stabilize v3.5), the full
>> cleanup/fix of this feature will need to be done for v3.6.  For v3.5, I
>> think the two patches from Russ Dill should be merged.   They are
>> targetted fixes and very well described.
>>
>> Kevin
>>
>
>
> Hi Kevin
>         The usb2 host of omap3/4/5 silicons has the following ips
>
> 1. UHH   (  /drivers/mfd/omap-usb-host.c ) -- platform driver
> 2. TLL    ( /drivers/mfd/omap-usb-host.c )
> 3. ehci    ( /drivers/usb/host/ehci-omap.c)  - platform driver
> 4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers
>
> The 3 platform drivers exists to make the ehci/ohci functional.
>
> The  UHH-TLL or usb host core driver is the parent platform driver of
> ehci and ohci.
> This parent driver doe the clock enable/disable which common for both
> ehci and ohci.
> takes care of common port setting and clocks during suspend and resume
> and ensures
> that there is no overwrites by ehci and ohci platform drivers.
>
> The commit id  354ab8567ae3107a8cbe7228c3181990ba598aac titled
> "Fix OMAP EHCI suspend/resume failure (i693)" was handling the clocks in
> the ehci driver it self, instead it should be handled by usb host core
> driver  as per above
> explanation. so, the UHH-TLL Driver should handle the changes done by
> 354ab8567ae3107a8cbe7228c3181990ba598aac.
>
>
> hence this patch removes the changed done by the commit id
> 354ab8567ae3107a8cbe7228c3181990ba598aac
>
> suppose if this patch is not included, then it will cause the
> following two problems
>
> 1.  crash during the system boot
>                        - observed in beagle xm , with NFS file system
>                                            the Ethernet is through
> ehci driver , since the ehci ports clocks are not handled properly
>                          by this commit id
> 354ab8567ae3107a8cbe7228c3181990ba598aac,  it leads to crash
>
> 2. crash during suspend/resume
>                   - observed in beagle xm with ram fs
>                                      if the ehci is driver is included
> and if it tries to suspend it leads to crash
>
> regards
> keshava


hi Felipe
        I request you to ack this patch;
this will enable the boot issue in beagle xm with NFS.
I will rework the patch with commit id
354ab8567ae3107a8cbe7228c3181990ba598aac by Anand gadiyar
after the TLL driver gets merged.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

"Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:

[...]

>>>
>>> hi kevin
>>>
>>> here is pm count log on beagle XM with the above patch:
>>
>> What are you meaning to show by this log?
>>
>> This dump shows that neither PER or CORE are hitting retention in idle.
>> Which sounds to me like you have not enabled UART runtime suspend:
>>
>> echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>> echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>> echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>> echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>>
>> My test with your patch shows that it fixes the oops during boot, and
>> doesn't hang during suspend, but that USB host is still preventing CORE
>> retention during idle (after UART runtime suspend is enabled.)
>>
>> This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>>
>> Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>>
>> Kevin
>
>
>
> Hi kevin
>        It woks. only the log was wrong. I was using no_console_suspend
> in boot args.
> i removed it. now I can see the core retention hits with USB host in Beagle XM.
> below is the log:
>

You are not reading what I write.

To repeat: your patch fixes the oops during boot, and the suspend hang
and now I see CORE hit retention in *suspend*.

However,  CORE does still not hit retention during *idle*.

Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.

Please investgate the *idle* problems caused by this driver.  

As I said way back in the beginning this thread.  The runtime PM of this
driver is leaving the device enabled.

To test idle retention, ensure the UART auto-suspend is enable for all
UARTS:

echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms

Then wait > 3 seconds and 'cat /debug/pm_debug/count'.  

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Alan Stern]

On Fri, 22 Jun 2012, Kevin Hilman wrote:

> As I said way back in the beginning this thread.  The runtime PM of this
> driver is leaving the device enabled.
> 
> To test idle retention, ensure the UART auto-suspend is enable for all
> UARTS:
> 
> echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
> echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
> 
> Then wait > 3 seconds and 'cat /debug/pm_debug/count'.  

This is probably a foolish question, but have you checked that the 
power/control attribute is set to "auto"?

Alan Stern

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>
> [...]
>
>>>>
>>>> hi kevin
>>>>
>>>> here is pm count log on beagle XM with the above patch:
>>>
>>> What are you meaning to show by this log?
>>>
>>> This dump shows that neither PER or CORE are hitting retention in idle.
>>> Which sounds to me like you have not enabled UART runtime suspend:
>>>
>>> echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>>> echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>>> echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>>> echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>>>
>>> My test with your patch shows that it fixes the oops during boot, and
>>> doesn't hang during suspend, but that USB host is still preventing CORE
>>> retention during idle (after UART runtime suspend is enabled.)
>>>
>>> This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>>>
>>> Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>>>
>>> Kevin
>>
>>
>>
>> Hi kevin
>>        It woks. only the log was wrong. I was using no_console_suspend
>> in boot args.
>> i removed it. now I can see the core retention hits with USB host in Beagle XM.
>> below is the log:
>>
>
> You are not reading what I write.
>
> To repeat: your patch fixes the oops during boot, and the suspend hang
> and now I see CORE hit retention in *suspend*.

thanks !

>
> However,  CORE does still not hit retention during *idle*.

here is the problem.

usb host retention in idle is not supported till now.
in current code, usb host cuts clock only in driver suspend not in bus
suspend ( auto suspend).
usb host driver need to use the  io daisy chain framework through io wakeup.
I will post the patches once ehci remote wakeup features stabilized in
omap3, omap4 and omap5 too.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Kevin Hilman]

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman <khilman@ti.com> wrote:
>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>
>> [...]
>>
>>>>>
>>>>> hi kevin
>>>>>
>>>>> here is pm count log on beagle XM with the above patch:
>>>>
>>>> What are you meaning to show by this log?
>>>>
>>>> This dump shows that neither PER or CORE are hitting retention in idle.
>>>> Which sounds to me like you have not enabled UART runtime suspend:
>>>>
>>>> echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
>>>> echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
>>>> echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
>>>> echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
>>>>
>>>> My test with your patch shows that it fixes the oops during boot, and
>>>> doesn't hang during suspend, but that USB host is still preventing CORE
>>>> retention during idle (after UART runtime suspend is enabled.)
>>>>
>>>> This happens on 3530/Overo, 3630/Beagle-xM and 3730/Overo
>>>>
>>>> Setting CONFIG_MFD_OMAP_USB_HOST=n allows CORE to hit retention again.
>>>>
>>>> Kevin
>>>
>>>
>>>
>>> Hi kevin
>>>        It woks. only the log was wrong. I was using no_console_suspend
>>> in boot args.
>>> i removed it. now I can see the core retention hits with USB host in Beagle XM.
>>> below is the log:
>>>
>>
>> You are not reading what I write.
>>
>> To repeat: your patch fixes the oops during boot, and the suspend hang
>> and now I see CORE hit retention in *suspend*.
>
> thanks !
>
>>
>> However,  CORE does still not hit retention during *idle*.
>
> here is the problem.
>
> usb host retention in idle is not supported till now.
> in current code, usb host cuts clock only in driver suspend not in bus
> suspend ( auto suspend).
>
> usb host driver need to use the  io daisy chain framework through io wakeup.
> I will post the patches once ehci remote wakeup features stabilized in
> omap3, omap4 and omap5 too.

Then I suggest you revert the changes that introduced this PM support
until it is fully working.  

The current form of the code prevents retention for the *whole* SoC
during idle because it prevents CORE retention.

The PM support for this driver was clearly not fully tested and should
be reverted until it can be tested and fully validated.

Please revert the PM changes for v3.5-rc.

Kevin
--
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

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Roger Quadros]

Hi,

On 06/22/2012 05:43 PM, Munegowda, Keshava wrote:
> On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman <khilman@ti.com> wrote:
>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>
>> [...]
>>

>>
>> You are not reading what I write.
>>
>> To repeat: your patch fixes the oops during boot, and the suspend hang
>> and now I see CORE hit retention in *suspend*.
> 
> thanks !
> 
>>
>> However,  CORE does still not hit retention during *idle*.
> 
> here is the problem.
> 
> usb host retention in idle is not supported till now.
> in current code, usb host cuts clock only in driver suspend not in bus
> suspend ( auto suspend).
> usb host driver need to use the  io daisy chain framework through io wakeup.
> I will post the patches once ehci remote wakeup features stabilized in
> omap3, omap4 and omap5 too.
> 

We are talking about CORE retention support during idle. How is IO daisy
chaining related to that? Doesn't IO daisy chain only apply when device
hits OFF?

regards,
-roger

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Mon, Jul 23, 2012 at 2:03 PM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> Hi,
>
> On 06/22/2012 05:43 PM, Munegowda, Keshava wrote:
>> On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org> wrote:
>>> "Munegowda, Keshava" <keshava_mgowda-l0cyMroinI0@public.gmane.org> writes:
>>>
>>> [...]
>>>
>
>>>
>>> You are not reading what I write.
>>>
>>> To repeat: your patch fixes the oops during boot, and the suspend hang
>>> and now I see CORE hit retention in *suspend*.
>>
>> thanks !
>>
>>>
>>> However,  CORE does still not hit retention during *idle*.
>>
>> here is the problem.
>>
>> usb host retention in idle is not supported till now.
>> in current code, usb host cuts clock only in driver suspend not in bus
>> suspend ( auto suspend).
>> usb host driver need to use the  io daisy chain framework through io wakeup.
>> I will post the patches once ehci remote wakeup features stabilized in
>> omap3, omap4 and omap5 too.
>>
>
> We are talking about CORE retention support during idle. How is IO daisy
> chaining related to that? Doesn't IO daisy chain only apply when device
> hits OFF?

when we see the usb bus suspend, then we disable the clocks of usb host to
enable to enable the retention in cpu idle; since we have disabled the clock of
usb host , we will not see the device connection at the controller
level, instead
the irq chain handler can detect it and corresponding irq can set the clocks.
this  same use case holds good for device OFF too.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Hi,

On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> the usb hub and device detection fails in beagle XM
> causeing NFS not functional. This affects the core retention too.
> The same commit logic needs to be revisted adhering to hwmod and
> device tree framework.
> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> 
> This patch is validated on BeagleXM with NFS support over
> usb ethernet and USB mass storage and other device detection.
> 
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>

Acked-by: Felipe Balbi <balbi@ti.com>

turns out this is causing other issues and another version of the patch
will be provided.

Greg, Alan, this is basically a git revert of the commit id listed
above.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Thu, Jul 19, 2012 at 3:50 PM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> Hi,
>
> On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
>> This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>> "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>> the usb hub and device detection fails in beagle XM
>> causeing NFS not functional. This affects the core retention too.
>> The same commit logic needs to be revisted adhering to hwmod and
>> device tree framework.
>> for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>> titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>>
>> This patch is validated on BeagleXM with NFS support over
>> usb ethernet and USB mass storage and other device detection.
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
>
> Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
>
> turns out this is causing other issues and another version of the patch
> will be provided.
>
> Greg, Alan, this is basically a git revert of the commit id listed
> above.
>
> --
> balbi


Thanks Felipe


regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Greg KH]

On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
> > This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> > "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> > the usb hub and device detection fails in beagle XM
> > causeing NFS not functional. This affects the core retention too.
> > The same commit logic needs to be revisted adhering to hwmod and
> > device tree framework.
> > for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> > titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> > 
> > This patch is validated on BeagleXM with NFS support over
> > usb ethernet and USB mass storage and other device detection.
> > 
> > Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> 
> Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> 
> turns out this is causing other issues and another version of the patch
> will be provided.
> 
> Greg, Alan, this is basically a git revert of the commit id listed
> above.

Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get
into 3.5.1, ok?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Greg KH]

On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote:
> On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
> > > This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> > > "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> > > the usb hub and device detection fails in beagle XM
> > > causeing NFS not functional. This affects the core retention too.
> > > The same commit logic needs to be revisted adhering to hwmod and
> > > device tree framework.
> > > for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> > > titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> > > 
> > > This patch is validated on BeagleXM with NFS support over
> > > usb ethernet and USB mass storage and other device detection.
> > > 
> > > Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> > 
> > Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> > 
> > turns out this is causing other issues and another version of the patch
> > will be provided.
> > 
> > Greg, Alan, this is basically a git revert of the commit id listed
> > above.
> 
> Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get
> into 3.5.1, ok?

Hm, that doesn't work as it doesn't apply to my tree :(

Can someone please update this against usb-next and send it to me?
Felipe?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Munegowda, Keshava]

On Fri, Jul 20, 2012 at 4:25 AM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote:
>> On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
>> > > This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
>> > > "Fix OMAP EHCI suspend/resume failure (i693)" is causing
>> > > the usb hub and device detection fails in beagle XM
>> > > causeing NFS not functional. This affects the core retention too.
>> > > The same commit logic needs to be revisted adhering to hwmod and
>> > > device tree framework.
>> > > for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
>> > > titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
>> > >
>> > > This patch is validated on BeagleXM with NFS support over
>> > > usb ethernet and USB mass storage and other device detection.
>> > >
>> > > Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
>> >
>> > Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
>> >
>> > turns out this is causing other issues and another version of the patch
>> > will be provided.
>> >
>> > Greg, Alan, this is basically a git revert of the commit id listed
>> > above.
>>
>> Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get
>> into 3.5.1, ok?
>
> Hm, that doesn't work as it doesn't apply to my tree :(
>
> Can someone please update this against usb-next and send it to me?
> Felipe?

Hi Greg
    yes, I will do this
I will send the v2 of this patch ASAP

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Alan Stern]

On Thu, 19 Jul 2012, Felipe Balbi wrote:

> Hi,
> 
> On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
> > This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
> > "Fix OMAP EHCI suspend/resume failure (i693)" is causing
> > the usb hub and device detection fails in beagle XM
> > causeing NFS not functional. This affects the core retention too.
> > The same commit logic needs to be revisted adhering to hwmod and
> > device tree framework.
> > for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
> > titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
> > 
> > This patch is validated on BeagleXM with NFS support over
> > usb ethernet and USB mass storage and other device detection.
> > 
> > Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
> 
> Acked-by: Felipe Balbi <balbi@ti.com>
> 
> turns out this is causing other issues and another version of the patch
> will be provided.
> 
> Greg, Alan, this is basically a git revert of the commit id listed
> above.

I have no objection to reverting the patch.  But on a related note,
have you had a chance to read my comment:

	http://marc.info/?l=linux-usb&m=134098423528415&w=2

?

Alan Stern