Alexander Kurpiers wrote: > Gadiyar, Anand wrote: > > Alan Stern wrote: > > > >> On Mon, 7 Jun 2010, Gadiyar, Anand wrote: > >> > >>> Hi all, > >>> > >>> On the OMAP3, we have a new hardware bug that causes the > >>> EHCI controller to lock up under heavy stress. The only > >>> known way to recover is to soft-reset the controller. > >>> > >>> I'm trying to implement some kind of recovery mechanism > >>> for the ehci-omap driver. Is there a way to inform the > >>> USB core that the root-hub and down-stream devices have > >>> been reset and need to be re-enumerated? > >>> > >> There's usb_hc_died(). It tells the core that the controller has > >> stopped working. The core then removes all devices below the root hub > >> and marks the root hub as non-operational (the state is set to > >> USB_STATE_NOTATTACHED). But there is no re-enumeration; from that > >> point on the root hub is unusable. > >> > >> This may not be exactly what you want. Perhaps a better match would be > >> usb_reset_device(), but that routine specifically excludes root hubs. > >> You might be able to adjust it in some way, though. > >> > >> Another alternative is simply to unregister the hcd and then > >> re-register it. > >> > >> > > > > (Sorry, hit send before completing the mail) > > > > Thanks! As a quick test, I built the driver as a module. And > > in the remove path, we soft-reset the controller anyway. > > > > > as I was the one who originally reported this problem, I can tell you > that soft-reset of EHCI is not enough. I had to reset UHH to recover - > sometimes losing EHCI for good, but I guess that was something else in > the end. Yes, we need to soft-reset the whole block through the UHH_SYSCONFIG, not just EHCI. I am still not able to make this mechanism work reliably. I've tried a "save-functional-registers, soft-reset, restore-registers" approach and it used to work a little better. Another problem is detecting the lockup itself... > > (I assume we are discussing the issue "Advisory 3.1.1.198 USB Host EHCI > May Stall when Running High Peak-bandwidth Demanding Use Cases" from > http://www.ti.com/litv/pdf/sprz278e). Yes, this is the one. It took a lot of effort from multiple folks (and a lot of time) to chase this bug down to it's root cause. I'm hoping we fix this in future silicon, but sadly current users are stuck. - Anand -- 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
