usb: musb: fix context save over suspend.

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.

Signed-off-by NeilBrown <[email protected]>

drivers/usb/musb/musb_core.c +1 -0

index fd34867..b6ccc02 100644
@@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
 	}
 
 	spin_unlock_irqrestore(&musb->lock, flags);
+	musb_save_context(musb);
 	return 0;
 }
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Neil,

Quoted 8 lines · NeilBrown

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".

Quoted 3 lines

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?

Quoted 17 lines

Signed-off-by NeilBrown <[email protected]>

drivers/usb/musb/musb_core.c +1 -0

index fd34867..b6ccc02 100644
@@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
 	}
 
 	spin_unlock_irqrestore(&musb->lock, flags);
+	musb_save_context(musb);
 	return 0;
 }
 

drivers/usb/musb/musb_core.c static int musb_resume_noirq(struct device *dev) · line 2242

Quoted 8 lines

drivers/usb/musb/musb_core.c +2 -0

@@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev)
 	 * unless for some reason the whole soc powered down or the USB
 	 * module got reset through the PSC (vs just being disabled).
 	 */
+	struct musb	*musb = dev_to_musb(dev);
+	musb_restore_context(musb);
 	return 0;
 }
 

- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ/SjTAAoJEBDE8YO64EfaHrsP/2bl4rP6L/tWLSZ+rNEdz6B+ Qo+HVOhnTVsOxgWbbd5VrfhE28jLoFGMslrLuI+geeCcJ1zgwNsahG9C11bygyfu 54hQgkmaxDJPDKAlalcy7VK9C6tOTgQV5iSbuRlemttK879dTrb+33zP6idn5+zK kxptY38fpmyojnl8gJiVa6Plik/apQcVr+GIx8CMwj+YQC5vkdg7cUEWyngfyk2C W0U4NceroS8NSjRbcFV3V6Q912TVjKzl+B2yxVD0OBaSK4BpHEncDBXiVx8APq87 4nDeBB5gDXi1rtN3YjcfDaFu0me5qzpYc3JFFidvdLTdXIdvxDzjHgMqsZB8ZBYC R0e5PtIw/62I90d63JkXZXVRTB7JeZsGfZFY2R7MxBab9or8zz0OyYwGWoW63vzH oFrwmAkWoD0IEKcfc8+dd99eicgZrmQL6FDWrEMsX+RS34LRtVU30SVAudRhY+CR MhNCjKyFySwx7wqkGgJl1ECl0Y6U4ua0v4bv7kdE6eyrgbQIkiGliSJ7DhWBPcP6 iMIOTwC7+LwPYP/MX2uYR3DXDfI0XwiqdtyzhD9LJe4PRol8zjozS2j0Y7FriItw jFqsgCgwDc9j8ufcpXf5ZynJYnlCG0iLuAPEUugZot83/CpxgU++A8cuHqUrOnhH 76L95rflUTkpiQ76ffP7
=jqXb
-----END PGP SIGNATURE-----

Quoted 14 lines · On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg <[email protected]>…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Neil,

Quoted 8 lines · NeilBrown

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".

Quoted 8 lines

Quoted 3 lines

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?

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.

Thanks,
NeilBrown

Quoted 29 lines

Quoted 16 lines

Signed-off-by NeilBrown <[email protected]>

drivers/usb/musb/musb_core.c +1 -0

index fd34867..b6ccc02 100644
@@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
 	}
 
 	spin_unlock_irqrestore(&musb->lock, flags);
+	musb_save_context(musb);
 	return 0;
 }
 

drivers/usb/musb/musb_core.c static int musb_resume_noirq(struct device *dev) · line 2242

Quoted 8 lines

drivers/usb/musb/musb_core.c +2 -0

@@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev)
 	 * unless for some reason the whole soc powered down or the USB
 	 * module got reset through the PSC (vs just being disabled).
 	 */
+	struct musb	*musb = dev_to_musb(dev);
+	musb_restore_context(musb);
 	return 0;
 }
 

- --
Regards,
Igor.

Quoted 14 lines · On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg <[email protected]>…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Neil,

Quoted 8 lines · NeilBrown

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".

Quoted 8 lines

Quoted 3 lines

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?

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.

Thanks,
NeilBrown

Quoted 29 lines

Quoted 16 lines

Signed-off-by NeilBrown <[email protected]>

drivers/usb/musb/musb_core.c +1 -0

index fd34867..b6ccc02 100644
@@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
    }
 
    spin_unlock_irqrestore(&musb->lock, flags);
+   musb_save_context(musb);
    return 0;
 }
 

drivers/usb/musb/musb_core.c static int musb_resume_noirq(struct device *dev) · line 2242

Quoted 8 lines

drivers/usb/musb/musb_core.c +2 -0

@@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev)
     * unless for some reason the whole soc powered down or the USB
     * module got reset through the PSC (vs just being disabled).
     */
+   struct musb     *musb = dev_to_musb(dev);
+   musb_restore_context(musb);
    return 0;
 }
 

- --
Regards,
Igor.

Quoted 18 lines · On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg <[email protected]>…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Neil,

Quoted 11 lines · NeilBrown

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.

Quoted 4 lines

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?

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.

Quoted 21 lines · NeilBrown

Quoted 18 lines · On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Neil,

Quoted 11 lines · NeilBrown

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.

Quoted 8 lines

Quoted 4 lines

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. ;)

Quoted 10 lines

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.

Quoted 7 lines

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 doing.)

Quoted 2 lines · On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman <[email protected]> wrote:

NeilBrown <[email protected]> writes:

Quoted 4 lines

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.

Odd. I plug in a mini-A cable, note that the 'mode' file holds 'a_idle' (sometimes just plugging in the cable isn't enough to trigger that, but sometimes it is....) and suspend/resume work perfectly. Though after resume it is back to b_idle.

unplug/replug and it is back to a_idle. suspend/resume and back to b_idle.

Quoted 4 lines

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 doing.)

I'm not sure it is possible for the device to be runtime suspended at this point. Certainly my device never is, even if it was just before the suspend sequence started. Something is waking it up...
(instruments the code).

Ahh - usb_suspend() calls choose_wakeup() which might call pm_runtime_resume() if the could be a need to reprogram the wakeup setting. As that is a 'might', the device might not be runtime-awake when 'suspend' runs.

Can you see if this, on top of my previous patch, does any better on your hardware?

Thanks,
NeilBrown

drivers/usb/musb/musb_core.c +4 -2

index 956db0e..00deb94 100644
@@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev)
 	}
 
 	spin_unlock_irqrestore(&musb->lock, flags);
-	musb_save_context(musb);
+	if (!pm_runtime_status_suspended(dev))
+		musb_save_context(musb);
 	return 0;
 }
 

@@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev)
 	 * module got reset through the PSC (vs just being disabled).
 	 */
 	struct musb	*musb = dev_to_musb(dev);
-	musb_restore_context(musb);
+	if (!pm_runtime_status_suspended(dev))
+		musb_restore_context(musb);
 	return 0;
 }