On Thu, 13 Nov 2014, Sebastian Andrzej Siewior wrote:
> On 11/07/2014 07:53 PM, Alan Stern wrote:
> >> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
> >> is gone. I don't see ehci-hcd doing this in resume, in fact I don't see
> >> ehci doing pm_runtime_* at all. So for ehci the device is probably
> >> always RPM_ACTIVE.
> >
> > No, it doesn't always have to be RPM_ACTIVE.
> >
> > Remember, the most common implementation of EHCI is the PCI version.
> > In drivers/pci/pci-driver.c, the pci_pm_suspend() routine calls
> > pm_runtime_resume().
>
> PCI? hehe. This is funny: I assumed that PCI is the most common and
> well tested version so I looked at the hooks of usb_hcd_pci_pm_ops.
> Didn't think to look at the bus ops / pci_dev_pm_ops.
>
> This resume function is only invoked since v3.15-rc1 via 7cd0602d7836
> ("PCI / PM: Resume runtime-suspended devices later during system
> suspend"). Before that it was in pci_pm_prepare() which probably did
> the same job.
>
> > EHCI controllers on other bus types might not behave so well. That
> > probably should be fixed in ehci_resume().
>
> Do you have the same thing in mind as for musb?
Yes.
> >> And still, if the HCD has a short suspend
> >> delay it might go into suspend before the khubd is invoked (but then it
> >> probably kills the status URB).
> >
> > We need the musb device to go to the RPM_ACTIVE state at some point
> > during the system suspend/resume, and to remain that way until after
> > the root hub has been resumed. Putting the
> >
> > pm_runtime_disable(dev);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> >
> > calls in musb_resume() is one way to accomplish this.
>
> Yes, this what I am doing…
>
> Thanks you for explaining things :)
You're welcome.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
