From a1fc1920aaaaeadc7cf9d80fc16e6b8eca722b44 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Thu, 13 Nov 2014 18:33:08 +0100 Subject: [PATCH] usb: musb: core: make sure musb is in RPM_ACTIVE on resume On am335x-evm with musb in host mode and using it as a wakeup source the following happens once the CPU comes out of suspend to ram: |PM: Wakeup source MPU_WAKE |PM: noirq resume of devices complete after 15.453 msecs |PM: early resume of devices complete after 2.222 msecs |PM: resume of devices complete after 507.351 msecs |Restarting tasks ... |------------[ cut here ]------------ |WARNING: CPU: 0 PID: 322 at drivers/usb/core/urb.c:339 usb_submit_urb+0x494/0x4c8() |URB cc0db380 submitted while active |[] (usb_submit_urb) from [] (hub_activate+0x2b8/0x49c) |[] (hub_activate) from [] (hub_resume+0x14/0x1c) |[] (hub_resume) from [] (usb_resume_interface.isra.4+0xdc/0x110) |[] (usb_resume_interface.isra.4) from [] (usb_resume_both+0x6c/0x13c) |[] (usb_resume_both) from [] (usb_runtime_resume+0x10/0x14) |[] (usb_runtime_resume) from [] (__rpm_callback+0x2c/0x60) |[] (__rpm_callback) from [] (rpm_callback+0x20/0x74) |[] (rpm_callback) from [] (rpm_resume+0x380/0x548) |[] (rpm_resume) from [] (rpm_resume+0x238/0x548) |[] (rpm_resume) from [] (__pm_runtime_resume+0x64/0x94) |[] (__pm_runtime_resume) from [] (usb_autopm_get_interface+0x18/0x5c) |[] (usb_autopm_get_interface) from [] (hub_thread+0x10c/0x115c) |[] (hub_thread) from [] (kthread+0xbc/0xd8) |---[ end trace 036aa5fe78203142 ]--- |hub 1-0:1.0: activate --> -16 |hub 2-0:1.0: activate --> -16 The reason for this backtrace is the attempt of the USB code to resume the HUB twice and thus enqueue the status URB twice. Alan Stern was a great help by explaining how the USB code supposed to work and what is most likely the problem. The root problem is that after resume the musb runtime-suspend state remains RPM_SUSPENDED. According to git log it RPM was added for the omap2430 platform. If I understand it correct the omap2430 invokes a get on musb once a cable is connected and a put once the cable is gone. In between the device could go auto-idle/off. Not sure what happens when the device goes into suspend but then I guess it was gadget only. On DSPS I see only a get in probe and put in remove function. This would forbid RPM from working but then the devices enterns suspended state anyway :) To get rid of this warning, I set the device state to RPM_ACTIVE which the expected state. Cc: Alan Stern Cc: Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi --- drivers/usb/musb/musb_core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 3345c945262f2f..f1dfe53515fb2d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2321,6 +2321,14 @@ static int musb_resume(struct device *dev) schedule_delayed_work(&musb->finish_resume_work, msecs_to_jiffies(20)); } + + /* + * The USB HUB code expects the device to be in RPM_ACTIVE once it came + * out of suspend + */ + pm_runtime_disable(dev); + pm_runtime_set_active(dev); + pm_runtime_enable(dev); return 0; }