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

Message ID 20161220184046.livxczyqrqub653l@lenoch
State New
Headers show

Commit Message

Ladislav Michl Dec. 20, 2016, 6:40 p.m. UTC
Hi Laurent,

On Sat, Nov 12, 2016 at 03:21:24AM +0200, Laurent Pinchart wrote:
> Hi Bin,
> 
> http://pandaboard.org/sites/default/files/board_reference/ES/750-2170-002-sch_revb.pdf
> 
> It would seem that the voltage is provided by the TWL6030. I'm not sure what's 
> turning it on as the MUSB driver doesn't seem to perform any set_vbus call in 
> the faulty configuration (I've traced musb_platform_set_vbus(), 
> omap2430_musb_set_vbus(), otg_set_vbus(), omap_usb_set_vbus() and 
> twl6030_set_vbus() and none of them get called).
> 
> An interesting point to note is that the TWL6030 gets probed after MUSB when 
> MUSB is configured in host mode only, and that happens after the call to 
> musb_start().

just gave 4.9.0 more testing on IGEPv2 board (DM3730 based), schematics here:
https://www.isee.biz/support/downloads/item/igepv2-rc-schematics

musb is configured in host only mode, driver compiled in. ID pin is grounded,
VBUS not connected, D+, D-, and GND are connected to self powered hub.

$ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=udlfb, 480M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 4: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
            |__ Port 4: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-omap3/3p, 12M

1) without following patch I'm getting:
   udlfb: wait for urb interrupted: ffffffc2 available: 0
   however, devices get enumerated

2) With the patch above, everything is working correctly, until I unplug all
   devices from hub. Usb core then tries to suspend port which leads to
   endless flood of:
   musb_bus_suspend 2586: trying to suspend as a_idle while active
   Disabling CONFIG_PM causes usb device enumeration stop working.

3) Few boards were still suffering from:
   musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_idle (90, <VBusValid), retry #3, port1 00000104
   but that turned out to be hardware problem as they came to customer with
   OTG connector, tvs diodes and capacitor unpopulated and customer's
   technician soldered C834 with wrong polarity, causing twl's charge
   pump surrending its job after a while.

Anyone has a clue how to fix 2?

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

Comments

Tony Lindgren Dec. 20, 2016, 8:59 p.m. UTC | #1
* Ladislav Michl <ladis@linux-mips.org> [161220 10:41]:
> Hi Laurent,
> 
> On Sat, Nov 12, 2016 at 03:21:24AM +0200, Laurent Pinchart wrote:
> > Hi Bin,
> > 
> > http://pandaboard.org/sites/default/files/board_reference/ES/750-2170-002-sch_revb.pdf
> > 
> > It would seem that the voltage is provided by the TWL6030. I'm not sure what's 
> > turning it on as the MUSB driver doesn't seem to perform any set_vbus call in 
> > the faulty configuration (I've traced musb_platform_set_vbus(), 
> > omap2430_musb_set_vbus(), otg_set_vbus(), omap_usb_set_vbus() and 
> > twl6030_set_vbus() and none of them get called).
> > 
> > An interesting point to note is that the TWL6030 gets probed after MUSB when 
> > MUSB is configured in host mode only, and that happens after the call to 
> > musb_start().
> 
> just gave 4.9.0 more testing on IGEPv2 board (DM3730 based), schematics here:
> https://www.isee.biz/support/downloads/item/igepv2-rc-schematics
> 
> musb is configured in host only mode, driver compiled in. ID pin is grounded,
> VBUS not connected, D+, D-, and GND are connected to self powered hub.
> 
> $ lsusb -t
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>         |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=udlfb, 480M
>         |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
>             |__ Port 4: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
>             |__ Port 4: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-omap3/3p, 12M
> 
> 1) without following patch I'm getting:
>    udlfb: wait for urb interrupted: ffffffc2 available: 0
>    however, devices get enumerated

So things are working..

> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 847d1c2..f043fb4 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2275,7 +2274,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
>  	 * 500 ms for some margin.
>  	 */
>  	pm_runtime_use_autosuspend(musb->controller);
> -	pm_runtime_set_autosuspend_delay(musb->controller, 500);
> +	pm_runtime_set_autosuspend_delay(musb->controller, 100);
>  	pm_runtime_enable(musb->controller);
>  	pm_runtime_get_sync(musb->controller);
> 
> 2) With the patch above, everything is working correctly, until I unplug all
>    devices from hub. Usb core then tries to suspend port which leads to
>    endless flood of:
>    musb_bus_suspend 2586: trying to suspend as a_idle while active
>    Disabling CONFIG_PM causes usb device enumeration stop working.

I think that's because musb needs to stay awake a little while to
negotiate with the PHY over ULPI whatever. Otherwise I think the PHY
might not idle properly, or might be in some unknown state?

If you have ID pin grounded, then a_idle is where we'd expect things
to be. That still does not explain why it's stuck in a loop though.

> 3) Few boards were still suffering from:
>    musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_idle (90, <VBusValid), retry #3, port1 00000104
>    but that turned out to be hardware problem as they came to customer with
>    OTG connector, tvs diodes and capacitor unpopulated and customer's
>    technician soldered C834 with wrong polarity, causing twl's charge
>    pump surrending its job after a while.

OK yeah host mode VBUS errors are common if the VBUS voltage does not
come up fast enough for musb.

> Anyone has a clue how to fix 2?

No idea.. Maybe try to add some printks to see why active is set
at that point?

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

Patch
diff mbox

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 847d1c2..f043fb4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2275,7 +2274,7 @@  musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	 * 500 ms for some margin.
 	 */
 	pm_runtime_use_autosuspend(musb->controller);
-	pm_runtime_set_autosuspend_delay(musb->controller, 500);
+	pm_runtime_set_autosuspend_delay(musb->controller, 100);
 	pm_runtime_enable(musb->controller);
 	pm_runtime_get_sync(musb->controller);