On Fri, Nov 07, 2014 at 06:54:21PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/06/2014 08:16 PM, Alan Stern wrote:
> >> --- now get back out of suspend ---
> >> - usb_resume() is invoked with different RPM status.
> >> - hub_activate() is invoked. The status URB is enqueued again, RPM
> >> remains unchanged.
> >> - aaaaand we are done
> >
> > Ah. In usb_resume(), what happened after usb_resume_both() returned?
> > The code says this:
> >
> > status = usb_resume_both(udev, msg);
> > if (status == 0) {
> > pm_runtime_disable(dev);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> > unbind_marked_interfaces(udev);
> > }
> >
> > So if usb_resume_both() returns 0, the runtime PM status is supposed to
> > get changed to RPM_ACTIVE by the pm_runtime_set_active() call.
>
> so it returns 0 but pm_runtime_set_active() return with -EBUSY:
> __pm_runtime_set_status() {
> …
> if (parent) {
> if (… && parent->power.runtime_status != RPM_ACTIVE) {
> error = -EBUSY;
> …
> if (error)
> goto out;
> …
>
> The parent is musb-hdrc.1.auto. The sort order of resume is:
>
> musb-dsps 47401c00.usb: bus resume
> => dsps_resume() (glue layer)
> musb-hdrc musb-hdrc.1.auto: bus resume
> => musb_resume(2328)
> and after musb_resume() completes I see usb_resume() being invoked (and
> the first hub resume).
> Later, once khubd kicks in, I see musb_runtime_resume() probably via
> usb_autopm_get_interface(hub).
>
> That means the musb-hcd is not RPM_ACTIVE after resume and this is what
> USB expects.
>
> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
shouldn't you have:
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
in musb_resume() ?
--
balbi
Attachment:
signature.asc
Description: Digital signature
