USB: musb: add two states to handle vbus error

When the MUSB is configured as host mode or OTG mode, the xceiv->state will be set to OTG_STATE_A_IDLE or OTG_STATE_B_IDLE unconditionally during init process. These init states can change to other states When the MUSB module detects id pin change, devices connect or disconnect.
But on some platforms(omap2, omap3), the id pin change can't raise IRQ request to the MUSB module, so on these platforms, the init xceiv->state will be A_IDLE or B_IDLE. Under this condition, when we want the MUSB to act as a host and hotplug a usb device in mini-B side of the cable, the MUSB will have a possibility to suffer power underrun under A_IDLE or B_IDLE state, So here adding these two states under which we can handle VBUSERROR IRQ.

Signed-off-by Wang Hui <[email protected]>

---
 drivers/usb/musb/musb_core.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

drivers/usb/musb/musb_core.c +2 -0

index b4bbf8f..655413c 100644
@@ -516,6 +516,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
 			 * another reset is due (at least for high speed,
 			 * to redo the chirp etc), it might work OK...
 			 */
+		case OTG_STATE_A_IDLE:
+		case OTG_STATE_B_IDLE:
 		case OTG_STATE_A_WAIT_BCON:
 		case OTG_STATE_A_WAIT_VRISE:
 			if (musb->vbuserr_retry) {

On omap2/3 series platforms, the musb can't raise id pin change detection interrupt, so we must change otg mode through sysfs interface manually. Currently when the musb is in B mode, if we want musb to be changed to A mode, we should plug a mini-A cable and then execute echo host > /sys/devices/platform/musb_hdrc/mode. But if the musb is in A mode, we can't change it to B mode through this method.
To solve this problem, add a process for sending end session request. This process works like this, if the musb is in A mode, it will send an end session request first, then it will follow original routine:
start a new session, during this session, it will identify whether A or B is plugging in the socket, then it will init controller to A or B mode according to its identification.

Usage: change cable as you desired,
change musb mode by #>echo host[peripheral] > /sys/devices/\
platform/musb_hdrc/mode,
then you will get required musb mode.

Signed-off-by Wang Hui <[email protected]>

---
 drivers/usb/musb/omap2430.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

drivers/usb/musb/omap2430.c +0 -0

index 3fe1686..b02897e 100644
@@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
 {

The whole musb_platform_set_mode() seems to be implemented
incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This

function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs.

Quoted 3 lines · Sergei Shtylyov

The whole musb_platform_set_mode() seems to be implemented
incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This

correct. It should be changing the id pin rules just like in tusb6010.c

Quoted 2 lines

function should control the ID pin override instead -- if the controller supports it. SRP must be initiated thru other means, i.e. 'srp' file in sysfs.

via musb_gadget_wakeup()

Thank you for your comments.
It is right that in this function, we should only change id pin rules according to user's choice, and
leave mode transition to the ISR.
But things are different on omap platforms, because the id pin change can't trigger ISR.
For example, when we configure the kernel, we choose musb working as OTG mode. Then we plug a mini-A or a mini-B cable in the socket, after that we execute insmod g_ether.ko, at this time, the musb will initialize to A or B working mode. how to change
its working mode from A to B or B to A at this time? I think if the platform can support id detection ISR, your method
is workable. But on omap platforms, we must change cable(id pin state) manually first, then let the controller to re-initiate a session forcibly. This action (clear/set session bit) don't 100% equal to send a SRP, and i don't really want to send a SRP too.

If without this function for omap platforms, we can change musb working mode only through rebooting kernel or rmmod/insmod gadget driver module.

On omap2/3 series platforms, the musb can't raise id pin change detection interrupt, so we must change otg mode through sysfs interface manually. Currently when the musb is in B mode, if we want musb to be changed to A mode, we should plug a mini-A cable and then execute echo host > /sys/devices/platform/musb_hdrc/mode.

But if the musb is in A mode, we can't change it to B mode through this method.
To solve this problem, add a process for sending end session request. This process works like this, if the musb is in A mode, it will send an end session request first, then it will follow original routine:
start a new session, during this session, it will identify whether A or B is plugging in the socket, then it will init controller to A or B mode according to its identification.

Usage: change cable as you desired,
change musb mode by #>echo host[peripheral] > /sys/devices/\
platform/musb_hdrc/mode,
then you will get required musb mode.

Signed-off-by Wang Hui <[email protected]>

---
 drivers/usb/musb/omap2430.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

drivers/usb/musb/omap2430.c +5 -0

index 3fe1686..b02897e 100644
@@ -194,6 +194,11 @@ int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
 {
 	u8	devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
 
+	if ((devctl & MUSB_DEVCTL_BDEVICE) == 0x0) {
+		devctl &= ~MUSB_DEVCTL_SESSION;
+		musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
+	}
+
 	devctl |= MUSB_DEVCTL_SESSION;
 	musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
 

Signature · 6 lines

1.5.6.5

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

Just curious about how to do this in a more automatic way.

I think setup a daemon to monitor the musb_hdrc mode and try to alter it's state via sysfs interface will work, but it may be error prone and not always desirable solution.

Can we query the id pin state periodically in the kernel and change to corresponding role?

Quoted 6 lines · Kan-Ru Chen

Just curious about how to do this in a more automatic way.

I think setup a daemon to monitor the musb_hdrc mode and try to alter it's state via sysfs interface will work, but it may be error prone and not always desirable solution.

Quoted 2 lines

Can we query the id pin state periodically in the kernel and change to corresponding role?

the transceiver has an interrupt for id pin changes. You can use that instead of polling.