Re: [PATCH] usb: musb: fix context save over suspend.

From: Kevin Hilman
Date: Tue Feb 12 2013 - 16:03:45 EST

NeilBrown <neilb@xxxxxxx> writes:

> On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg <grinberg@xxxxxxxxxxxxxx>
> wrote:
>> Hash: SHA1
>> Hi Neil,
>> On 01/21/13 11:28, NeilBrown wrote:
>> >
>> >
>> > The standard suspend sequence involves runtime_resuming
>> > devices before suspending the system.
>> > So just saving context in runtime_suspend and restoring it
>> > in runtime resume isn't enough. We must also save in "suspend"
>> > and restore in "resume".
>> >
>> > Without this patch, and OMAP3 system with off_mode enabled will find
>> > the musb port non-functional after suspend/resume. With the patch it
>> > works perfectly.
>> Hmmm... Some time ago, this has been removed in
>> 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path)
>> Am I missing something? Or things changed and now this patch is correct?
> Hi Igor,
> thanks for alerting me to that patch .... does anyone else get the feeling
> that power management to too complex to be understood by a mere human?

Yes. ;)

> That commit (5d193ce8) suggests that the musb-hdrc device is an
> 'omap_device', or maybe has a PM domain set to something else.
> However it isn't/doesn't. dev->pm_domain is NULL. So no PM domain layer
> will ever call the musb_core musb_runtime_suspend/resume.
> The parent device - musb-omap2430 - is an omap device, does have pm_domain
> set, and does have its omap2430_runtime_suspend/resume called for system
> suspend and so the context for that device is saved and restored.
> However that doesn't help the context for musb-hdrc.
> Whether musb ever was an omap_device is beyond my archaeological skills to
> determine.
> Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever
> the various possible parents that had domains?
> Are you able to defend your earlier patch in today's kernel? It
> certainly causes my device not to work properly.

Sorry for the delay here, I'm back to a place where I can test this on
real hardware.

My patch was fixing a real hang when musb was built-in (or loaded), in
host-mode (mini-A cable attached) but no devices attached. I just tried
to reproduce this, and with your patch, the system hangs during suspend.

That being said, your description makes sense why this context
save/restore is needed. Perhaps your patch needs to add a check whether
the device is runtime suspended (I gather this is what Ruslan's patch is

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at