Am 19.12.2013 00:40, schrieb Grazvydas Ignotas:
On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi <balbi@xxxxxx> wrote:
Hi,
On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaumann@xxxxxxxxxxxxxx wrote:
From: Andreas Naumann <anaumann@xxxxxxxxxxxxxx>
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.
I'm a bit short on time at the moment, but shall I have a go on another
version of the patch with the init-variable as atomic_t?
Andreas
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
