On Thu, 30 Dec 2010, Sarah Sharp wrote: > On Thu, Dec 30, 2010 at 12:24:16PM -0500, Alan Stern wrote: > > In the meantime you could disable autosuspend for USB-3 hubs: add a > > check before the usb_enable_autosuspend() call in hub_probe(). > > It seems like I should also disable autosuspend for other USB 3.0 > devices. Or just for SuperSpeed devices. Are there any such devices for which autosuspend is enabled by default? > Should I refuse to set the level to auto when power/control is > written for a USB 3.0 device? You can't; that would require modifications to the PM core. > Perhaps with a warning in dmesg that USB > 3.0 device suspend is not supported yet? You could put a WARN_ONCE() at an appropriate spot. Be careful not to trigger the warning when a root hub is suspended. What about system suspend? > > Still, is there any simple way to put the entire device, including all > > its functions, into a low-power suspend state? > > Yes. You can put a device into device suspend (U3) without explicitly > suspending all its functions, although the mechanisms are slightly > different than USB 2.0. We could also suspend all the functions and > then put the device into U3. (Suspending all the functions does not > trigger the device to go into U3 automatically.) > > We'd have to enable remote wake on all functions with a SetFeature > FUNCTION_SUSPEND with Function Remote Wake Enabled bit set. It has to > be sent to the first interface described by the IAD (or the first > interface on the device if it has only one interface). That same > control transfer also contains bits to tell the function to go into a > low power state or stay active. From reading section 9.2.5.4, I think > it doesn't matter whether we put the functions into function suspend; > they will still be able to signal remote wake when the device is > suspended in either state. > > There's also some control over when a USB 3.0 hub signals a remote wake. > A Set Port Feature PORT_REMOTE_WAKE_MASK can control (for each port) > whether the hub sends resume signaling for a connect, disconnect, or > overcurrent event. I think we'd want to enable remote wake for all of > those. > > To put the device into suspend, we would then send the parent hub a Set > Port Feature PORT_LINK_STATE control transfer with the link state set to > '3' for U3. When a remote wakeup happens, the device will transition to > the active state (U0) and send a Function Wake Notification to let the > host know which function caused the remote wakeup. We could see several > notifications if more than one function woke up. > > I think for now we could safely ignore those asynchronous notifications > and just assume the device is awake when we see the port status change. > The xHCI host is designed to generate a Device Notification Event when > it receives a function wake notification, but that's turned off by > default. > > The only tricky part would be if we chose to suspend all the functions > before putting the device into U3. The functions that didn't signal the > remote wake would still be in a low power state after the device resume, > so we would have to wake them up. At this point, I'm not clear whether > they should be woken up with a SetFeature FUNCTION_SUSPEND > message, or a Clear Feature FUNCTION_SUSPEND message. The spec is not > very explicit in section 9.4.1 and 9.4.9. For now I think it will be best to avoid suspending individual functions. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
