* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
