mirror of
https://github.com/torvalds/linux.git
synced 2024-12-27 05:11:48 +00:00
a1fc1920aa
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 |[<c0348e64>] (usb_submit_urb) from [<c0340f94>] (hub_activate+0x2b8/0x49c) |[<c0340f94>] (hub_activate) from [<c03411dc>] (hub_resume+0x14/0x1c) |[<c03411dc>] (hub_resume) from [<c034be10>] (usb_resume_interface.isra.4+0xdc/0x110) |[<c034be10>] (usb_resume_interface.isra.4) from [<c034beb0>] (usb_resume_both+0x6c/0x13c) |[<c034beb0>] (usb_resume_both) from [<c034cca4>] (usb_runtime_resume+0x10/0x14) |[<c034cca4>] (usb_runtime_resume) from [<c02bbd80>] (__rpm_callback+0x2c/0x60) |[<c02bbd80>] (__rpm_callback) from [<c02bbdd4>] (rpm_callback+0x20/0x74) |[<c02bbdd4>] (rpm_callback) from [<c02bcc48>] (rpm_resume+0x380/0x548) |[<c02bcc48>] (rpm_resume) from [<c02bcb00>] (rpm_resume+0x238/0x548) |[<c02bcb00>] (rpm_resume) from [<c02bd08c>] (__pm_runtime_resume+0x64/0x94) |[<c02bd08c>] (__pm_runtime_resume) from [<c034b5a4>] (usb_autopm_get_interface+0x18/0x5c) |[<c034b5a4>] (usb_autopm_get_interface) from [<c03438b8>] (hub_thread+0x10c/0x115c) |[<c03438b8>] (hub_thread) from [<c005a70c>] (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 <stern@rowland.harvard.edu> Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com> |
||
---|---|---|
.. | ||
am35x.c | ||
blackfin.c | ||
blackfin.h | ||
cppi_dma.c | ||
cppi_dma.h | ||
da8xx.c | ||
davinci.c | ||
davinci.h | ||
jz4740.c | ||
Kconfig | ||
Makefile | ||
musb_am335x.c | ||
musb_core.c | ||
musb_core.h | ||
musb_cppi41.c | ||
musb_debug.h | ||
musb_debugfs.c | ||
musb_dma.h | ||
musb_dsps.c | ||
musb_gadget_ep0.c | ||
musb_gadget.c | ||
musb_gadget.h | ||
musb_host.c | ||
musb_host.h | ||
musb_io.h | ||
musb_regs.h | ||
musb_virthub.c | ||
musbhsdma.c | ||
musbhsdma.h | ||
omap2430.c | ||
omap2430.h | ||
tusb6010_omap.c | ||
tusb6010.c | ||
tusb6010.h | ||
ux500_dma.c | ||
ux500.c |