usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

[Tony Lindgren]

Looks like we can get VBUS interrupt before the ID interrupt
at least with a Motorola LapDock if the USB mini-A cable is
inserted slowly at the omap end. This issue also prevents
enumerating the LapDock during the boot.

It seems that the issue is caused by musb getting confused and
trying to do things on it's own as the LapDock provides VBUS.
Fix the issue by disconnecting the transceiver before setting the
host mode if the previous state was VBUS, and check that musb
is in a sane state with the session bit cleared before we attempt
to start the session.

With this patch the LapDock is properly enumerated during the
boot and on slow insertion after a cold boot. This means that
the LapDock can be used for both power and keyboard with at
least omap panda es.

However, there seems to be a separate issue with musb not
resetting properly after a warm reset which also leads to
devices not enumerating.

Signed-off-by: Tony Lindgren <tony@atomide.com>

---

Can you guys please test that this does not cause regressions
on other devices when connecting USB devices?

--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -251,6 +251,20 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
 }
 EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
+static void omap_musb_disconnect(struct musb *musb, struct omap2430_glue *glue)
+{
+	int loops = 100;
+
+	omap_control_usb_set_mode(glue->control_otghs,
+				  USB_MODE_DISCONNECT);
+	while (loops--) {
+		u8 devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+		if (!(devctl & MUSB_DEVCTL_SESSION))
+			break;
+		dev_dbg(dev, "disconnecting: %02x\n", devctl);
+	}
+}
+
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
 	struct musb *musb = glue_to_musb(glue);
@@ -258,6 +272,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	struct musb_hdrc_platform_data *pdata = dev->platform_data;
 	struct omap_musb_board_data *data = pdata->board_data;
 	struct usb_otg *otg = musb->xceiv->otg;
+	int disconnect = 0;
 
 	switch (glue->status) {
 	case OMAP_MUSB_ID_GROUND:
@@ -265,9 +280,13 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 
 		otg->default_a = true;
 		musb->xceiv->state = OTG_STATE_A_IDLE;
+		if (musb->xceiv->last_event == USB_EVENT_VBUS)
+			disconnect = 1;
 		musb->xceiv->last_event = USB_EVENT_ID;
 		if (musb->gadget_driver) {
 			pm_runtime_get_sync(dev);
+			if (disconnect)
+				omap_musb_disconnect(musb, glue);
 			omap_control_usb_set_mode(glue->control_otghs,
 				USB_MODE_HOST);
 			omap2430_musb_set_vbus(musb, 1);

Re: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [130503 10:55]:
> Looks like we can get VBUS interrupt before the ID interrupt
> at least with a Motorola LapDock if the USB mini-A cable is
> inserted slowly at the omap end. This issue also prevents
> enumerating the LapDock during the boot.
> 
> It seems that the issue is caused by musb getting confused and
> trying to do things on it's own as the LapDock provides VBUS.
> Fix the issue by disconnecting the transceiver before setting the
> host mode if the previous state was VBUS, and check that musb
> is in a sane state with the session bit cleared before we attempt
> to start the session.
> 
> With this patch the LapDock is properly enumerated during the
> boot and on slow insertion after a cold boot. This means that
> the LapDock can be used for both power and keyboard with at
> least omap panda es.
> 
> However, there seems to be a separate issue with musb not
> resetting properly after a warm reset which also leads to
> devices not enumerating.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> ---
> 
> Can you guys please test that this does not cause regressions
> on other devices when connecting USB devices?
> 

Sorry forgot to stg refresh, one line was missing. Updated patch
below.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Wed, 1 May 2013 14:28:46 -0700
Subject: [PATCH] usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

Looks like we can get VBUS interrupt before the ID interrupt
at least with a Motorola LapDock if the USB mini-A cable is
inserted slowly at the omap end. This issue also prevents
enumerating the LapDock during the boot.

It seems that the issue is caused by musb getting confused and
trying to do things on it's own as the LapDock provides VBUS.
Fix the issue by disconnecting the transceiver before setting the
host mode if the previous state was VBUS, and check that musb
is in a sane state with the session bit cleared before we attempt
to start the session.

With this patch the LapDock is properly enumerated during the
boot and on slow insertion after a cold boot. This means that
the LapDock can be used for both power and keyboard with at
least omap panda es.

However, there seems to be a separate issue with musb not
resetting properly after a warm reset which also leads to
devices not enumerating.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -251,6 +251,21 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
 }
 EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
+static void omap_musb_disconnect(struct musb *musb, struct omap2430_glue *glue)
+{
+	struct device *dev = musb->controller;
+	int loops = 100;
+
+	omap_control_usb_set_mode(glue->control_otghs,
+				  USB_MODE_DISCONNECT);
+	while (loops--) {
+		u8 devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+		if (!(devctl & MUSB_DEVCTL_SESSION))
+			break;
+		dev_dbg(dev, "disconnecting: %02x\n", devctl);
+	}
+}
+
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
 	struct musb *musb = glue_to_musb(glue);
@@ -258,6 +273,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	struct musb_hdrc_platform_data *pdata = dev->platform_data;
 	struct omap_musb_board_data *data = pdata->board_data;
 	struct usb_otg *otg = musb->xceiv->otg;
+	int disconnect = 0;
 
 	switch (glue->status) {
 	case OMAP_MUSB_ID_GROUND:
@@ -265,9 +281,13 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 
 		otg->default_a = true;
 		musb->xceiv->state = OTG_STATE_A_IDLE;
+		if (musb->xceiv->last_event == USB_EVENT_VBUS)
+			disconnect = 1;
 		musb->xceiv->last_event = USB_EVENT_ID;
 		if (musb->gadget_driver) {
 			pm_runtime_get_sync(dev);
+			if (disconnect)
+				omap_musb_disconnect(musb, glue);
 			omap_control_usb_set_mode(glue->control_otghs,
 				USB_MODE_HOST);
 			omap2430_musb_set_vbus(musb, 1);

Re: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

[Felipe Balbi]

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

On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [130503 10:55]:
> > Looks like we can get VBUS interrupt before the ID interrupt

how can this happen ? VBUS interrupt happens when you connect to a port
which is sourcing VBUS to you, while ID interrupt happens when ID is
grounded, meaning that you should be sourcing VBUS.

Have you hacked a Hub to backfeed 5V to OMAP by any chance ?

-- 
balbi

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

Re: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [130515 07:11]:
> On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [130503 10:55]:
> > > Looks like we can get VBUS interrupt before the ID interrupt
> 
> how can this happen ? VBUS interrupt happens when you connect to a port
> which is sourcing VBUS to you, while ID interrupt happens when ID is
> grounded, meaning that you should be sourcing VBUS.

Yes, in this case we get both interrupts and the order depends
on how fast/slow the cable is inserted.
 
> Have you hacked a Hub to backfeed 5V to OMAP by any chance ?

..as that's how the LapDock seems to behave backfeeding 5V.

It would be interesting to take a look at the signaling on it,
but I think my old beagle sniffer is fried.

Looking at the "Figure 6-1: Common State Diagram" on page 32 in
"USB_OTG_and_EH_3-0_release_1_1_10May2012.pdf" the logic is the
following depending on the order of interrupt:

start -> id ground -> a_idle -> a_wait_vrise -> a_wait_bcon...

or

start -> vbus -> b_idle -> id ground -> a_idle -> a_wait_vrise ->
a_wait_bcon...

I don't think having the VBUS there actually violates that if
we just should follow the ID state and accept that a_wait_vrise
is already satisfied and not even try to turn the VBUS at MUSB
end in that case.

Regards,

Tony