On 09/19/2014 12:37 PM, Michael Trimarchi wrote: > Hi Roger > > On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros <rog...@ti.com> wrote: >> Hi Michael, >>
<snip> >>>>> >>>>> It should be noted that the external HUB must be prevented from >>>>> autosuspend >>>>> otherwise the resume fails. >>>> >>>> OK. I was able to reproduce the issue on my beagleboard as well. The key >>>> to reproduce the issue is to use a device which has autosuspend working. >>>> Earlier I was using a mass storage device so couldn't reproduce the issue. >>>> On using a HUB I could see the issue. Debugging this issue is on my action >>>> list. >>>> >>> >>> I will keep an eye out for the fix if it is possible. The implementation of >>> the remote resume workaround as listed in the sprz306d.pdf seems to hack >>> into the core EHCI drivers and limits you to a single USB host. >>> >> >> Please see Advisory 1.1.33 HSUSB Interoperability Issue with SMSC USB3320 PHY >> (sprz306d errata doc). >> >> It seems ULPI suspend/resume is broken and there is no workaround. So you >> have to >> prevent the USB device connected at root port from suspending. >> > > It's very important to understand if this affect even OMAP4 and > tusb1210 that is suggested by TI. > This particular issue was fixed in omap3630 ES1.1 onwards. But that doesn't mean OMAP4 is free of issues around USB EHCI. 4430 brought it's own set of issues which were fixed in 4460. But there were still some issues requiring software workaround especially around USB suspend/resume. e.g. There is still an issue with both 4430 and 4460 called i701 (USB Host - Possible Interoperability With External PHY At Resume Time) which is observed on certain PHYs (at least not on usb3320). There is a software workaround for that. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
