On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi <ba...@ti.com> wrote: > Hi, > > On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote: >> From: Andreas Naumann <anaum...@ultratronik.de> >> >> This is a hard to reproduce problem which leads to non-functional >> USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit >> e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore >> of OTG_INTERFSEL over suspend. >> Since the resume function is also called early in driver init, it uses a >> non-initialized value (which is 0 and a non-supported setting in DM37xx >> for INTERFSEL). Shortly after the correct value is set. Apparently this >> works most time, but not always. > > yeah, but the problem is not on the glue layer. The bug is omap_device > and pm_runtime not agreeing on device's state. I suppose there was a fix > for that recently in linux-omap@vger mailing list.
You mean this: http://marc.info/?t=138444882600003&r=1&w=2 ? This looks like a different issue during suspend, this problem is at startup. Both musb_core and omap2430.c expect hardware to be disabled on startup, and that works as expected. The problem is on first pm_runtime_get_sync(), which results in first runtime_resume() call, musb_core checks for first resume and doesn't load yet-unset context in that case, however glue does and breaks things. We have this problem since 3.2. GraÅžvydas -- 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