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?
>> 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 :)
> Alan Stern
>
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
