On Fri, Nov 11, 2011 at 12:27:32PM -0500, Alan Stern wrote: > On Fri, 11 Nov 2011, Sarah Sharp wrote: > > > One thing I've been trying to figure out is how device suspend (U3) and > > link PM (U1/U2) will interact. One complication is that you can't > > directly go from U1 or U2 into U3; instead you have to bring the device > > back into U0 and then put it in U3. That means when we suspend a > > device, we'll have to disable the device from entering U1 and U2, and > > disable the parent hub's port U1/U2 timeouts. Then when we resume a > > device we'll have to re-enable the device and hub U1/U2 timeouts. > > Can you tell the hub to prevent the port from going into U1/U2, or does > this require communication with the device? Just curious; I don't > think it matters very much. You can set the hub timeout to zero, which will disable U1/U2 entry. The device may ask to go into a deeper link state, but the hub will refuse when the timeout is set to zero. However, I'm not sure what a hub will do if the timeout is set to zero and the child device is in U1 or U2. I'd have to look at the spec to see if the hub will bring the device back into U0. If not, we'd need to send the SetFeature request to the device to disable U1 and U2. > > The bit I'm struggling with that there are places where the USB core > > disables autosuspend (like when we're installing to a new configuration) > > by calling usb_autoresume_device. Should U1 and U2 be disabled in that > > case? Any transfer that's sent will wake up any links in a lower power > > state, so I can't really see a need to disable it. Do you? > > No, I don't think it is necessary. These things aren't time-critical; > a little extra delay for the links to power up now and then won't > matter. Ok, makes sense. > If any drivers really do want to suppress LPM on the paths to their > devices, there should be a new API specifically that purpose. Yes, I'm not sure whether to design that into the first pass, or wait until we find drivers that need to disable link PM or disable the hub timeouts. Right now, the only USB 3.0 devices I know of are mass storage devices, a Black Magic video capture device that doesn't work under Linux, and the Point Grey webcam. I'm not sure how any of them will react to LPM yet. The good thing is that the device can always refuse to enter a lower power state, so if a device doesn't implement LPM properly, it can always refuse the LPM request, which shouldn't lead to USB disconnects like we see with device suspend (U3). Speaking of device suspend, have you ever found that whether USB device suspend and resume works depends on which system the device is attached to? I've had some slides forwarded to me that have some interesting electrical captures that show that if a host controller is too fast in enabling SOFs after resume signaling ends (where too fast is < 1us), the device doesn't have time to enable its high speed terminations. The SOF ends up looking like a device disconnect, and it's possible that the host might then report it as a low speed device. That sounds pretty similar to the resume fails that we've been assuming are really the device's fault. The experiments that the people did showed that some host controllers were pretty consistent about the minimum time between the end of resume and the start of the SOF, while others were pretty random, and the SOF would sometimes fall in the 1us window, causing random disconnects. This was sort of a shift in thinking for me, since we've been blaming "bad devices" for years without wondering if the host controller behavior was also causing resume failures. I don't think there's anything we can do, software-wise, to fix this issue, but it's an interesting thing to consider when distros decide whether to ship a udev rule that turns on auto-suspend for a particular device. For these devices that are slow to enable terminations, resume might work on some systems but fail on others. 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
