Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Andreas Naumann <dev@andin.de>]

Am 19.12.2013 00:40, schrieb Grazvydas Ignotas:
> On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi <balbi@ti.com> wrote:
>> Hi,
>>
>> On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaumann@ultratronik.de wrote:
>>> From: Andreas Naumann <anaumann@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.

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html