On Thu, 11 Oct 2012, Sarah Sharp wrote:
> Thinking about this further, USB 2.1 devices need to be brought out of
> their low power link state (L1) before they are suspended. Some xHCI
> host controllers have hardware-driven USB 2.1 LPM, so the device could
> have been put in L1 before hibernation. Therefore we need to suspend
> USB 2.1 and USB 3.0 devices before we hibernate.
I need to go through the LPM document more carefully before I can
answer fully. However, what about disabling LPM instead of going all
the way into suspend? For USB 2.1 devices at least?
> Should we suspend all USB 2.0 devices, or should we only suspend devices
> with bcdUSB 2.1 and higher? If we only suspend the USB 2.1 devices,
> will that work if there is a USB 2.1 hub with USB 2.0 children?
Here's more or less what I'd like to do (I don't know which parts will
work with USB-3 hubs and devices, though):
In generic_suspend, skip calling usb_port_suspend for
FREEZE and PRETHAW events (just as we do now).
In usb_port_suspend, set the wakeup feature as we do now.
But if the event is for a system sleep, don't set the
port-suspend feature but do disable LPM.
In hub_suspend, if the event is a runtime suspend,
clear the port-suspend feature for any children that
have wakeup enabled. Keep track of which ports they
were on for later use.
In hub_resume, if the event is a runtime resume, queue
a runtime-resume request for the devices attached to
those ports. Also, prevent the hub from going back
into runtime suspend until all those resumes have
completed.
Partly this is to optimize system suspend, and partly it is to work
around the child-wakeup-request vs. port-suspend race. At this time
I'm not sure if it will interact correctly with USB >=2.1 LPM.
Alan Stern
--
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
