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. Should I refuse to set the level to auto when power/control is written for a USB 3.0 device? Perhaps with a warning in dmesg that USB 3.0 device suspend is not supported yet? > > > > Remote wake has also changed for USB 3.0 devices. Instead of a "device" > > > > waking up, there are "functions" on the device that wake up. The old > > > > SetFeature DEVICE_REMOTE_WAKEUP isn't valid anymore, and instead the USB > > > > core needs to set remote wakeup for each function on the device. > > > > > > Is this using the word "function" in a different sense from the USB-2.0 > > > spec? In there, "function" means essentially the same thing as > > > "non-hub USB device" means in the kernel. > > > > This is a different meaning. A non-hub device is defined by the USB 3.0 > > spec as a "peripheral device" and a hub is, well, a hub device. A > > function in the USB 3.0 sense is a set of related interfaces on one > > device, described by an interface association descriptor (IAD). All USB > > 3.0 devices must have at least one IAD and one function. > > > > Say you could have a USB 3.0 device with a webcam and speaker. There > > might be two IADs, with one describing the video interfaces that fall > > into one function, and another IAD that describes the audio interfaces > > as another function. Then when you're recording video but you're not > > using the speakers, you could suspend the audio function. > > Originally we decided that the USB core would support suspending entire > devices, not individual interfaces. Looks like we may have to rethink > that policy. I haven't seen any industry traction on actually using multiple functions. Most of the USB 3.0 devices I've seen have only one interface, and therefore only one function. I think the device vendors are much more excited about link power management, but USB 3.0 is still new, so we'll see if and when we need to revisit that design decision. > 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. > > > > Could there be something wrong with the USB core PM runtime code? It > > > > seems like if a device fails to suspend and is resumed, > > > > usb_autoresume_device() ought to succeed... > > > > > > Yes, there's a bug. usb_runtime_suspend() returns the status value it > > > receives from usb_suspend_both(). However the PM core reacts badly > > > unless the return code is 0, -EAGAIN, or -EBUSY. If usb_suspend_both() > > > returns anything other than 0, usb_runtime_suspend() should set status > > > to -EBUSY before returning it. > > > > Ok, what about in usb_runtime_resume()? Does the status need to get > > overwritten there? > > No. Any nonzero value is essentially an unrecoverable error. Right > now we don't have any cleanup code for such things; it's not clear what > that code would want to do. Ok, I'll make a patch. Sarah Sharp -- 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
