Re: [PATCH 0/4] musb fixes for v4.9-rc cycle

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html