[0/4] musb fixes for v4.9-rc cycle
diff mbox

Message ID 20161108144934.GK2428@atomide.com
State New
Headers show

Commit Message

Tony Lindgren Nov. 8, 2016, 2:49 p.m. UTC
* Ladislav Michl <ladis@linux-mips.org> [161108 06:39]:
> Hi Tony,
> 
> On Mon, Nov 07, 2016 at 02:50:16PM -0700, Tony Lindgren wrote:
> > Hi all,
> > 
> > Here are musb fixes for the issues that I've been able to track down.
> > Not sure if these will help with the problem Ladis was seeing as I'm
> > not able to reproduce that one it seems.
> 
> I still need 87326e858448c40e32f142c0b8dcc59d7b27c641 (usb: musb: Remove
> extra PM runtime calls from 2430 glue layer) reverted, but I'm happy with
> that solution so far.

Weird, I have not figured out what happens there..

The only thing I'm still wondering about is if phy-twl4030-usb.c
is losing ID pin interrupts occasionally but have not been
able to verify that. Maybe try the following additional patch
and see if it makes any difference?

Regards,

Tony

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

Comments

Tony Lindgren Nov. 8, 2016, 2:55 p.m. UTC | #1
* Tony Lindgren <tony@atomide.com> [161108 07:50]:
> * Ladislav Michl <ladis@linux-mips.org> [161108 06:39]:
> > Hi Tony,
> > 
> > On Mon, Nov 07, 2016 at 02:50:16PM -0700, Tony Lindgren wrote:
> > > Hi all,
> > > 
> > > Here are musb fixes for the issues that I've been able to track down.
> > > Not sure if these will help with the problem Ladis was seeing as I'm
> > > not able to reproduce that one it seems.
> > 
> > I still need 87326e858448c40e32f142c0b8dcc59d7b27c641 (usb: musb: Remove
> > extra PM runtime calls from 2430 glue layer) reverted, but I'm happy with
> > that solution so far.
> 
> Weird, I have not figured out what happens there..
> 
> The only thing I'm still wondering about is if phy-twl4030-usb.c
> is losing ID pin interrupts occasionally but have not been
> able to verify that. Maybe try the following additional patch
> and see if it makes any difference?

And eventually the glue layers only should need to do this on
init:

pm_runtime_enable(glue->dev);

And this on the exit path:

pm_runtime_disable(glue->dev);

And musb core as the child device should keep things awake
when needed.

Regards,

Tony
--
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
Ladislav Michl Nov. 8, 2016, 5:19 p.m. UTC | #2
On Tue, Nov 08, 2016 at 07:55:50AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [161108 07:50]:
> > Weird, I have not figured out what happens there..
> > 
> > The only thing I'm still wondering about is if phy-twl4030-usb.c
> > is losing ID pin interrupts occasionally but have not been
> > able to verify that. Maybe try the following additional patch
> > and see if it makes any difference?
> 
> And eventually the glue layers only should need to do this on
> init:
> 
> pm_runtime_enable(glue->dev);
> 
> And this on the exit path:
> 
> pm_runtime_disable(glue->dev);
> 
> And musb core as the child device should keep things awake
> when needed.

Tested your patch, does not work, does not trigger "USB link status err"
both without and with pm_runtime_enable/disable.

Best regards,
	ladis
--
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

Patch
diff mbox

--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -304,6 +304,17 @@  static enum musb_vbus_id_status
 				status &= ~BIT(7);
 			else
 				twl->vbus_supplied = true;
+
+			/* Recheck status again for ID pin */
+			if (!(status & BIT(2))) {
+				msleep(200);
+				status = twl4030_readb(twl,
+						       TWL_MODULE_PM_MASTER,
+						       STS_HW_CONDITIONS);
+				if (status < 0)
+					dev_err(twl->dev, "USB link status err %d\n",
+						status);
+			}
 		}
 
 		if (status & BIT(2))