On Tue, Aug 30, 2011 at 05:40:53PM +0800, Andiry Xu wrote: > On Mon, 2011-08-29 at 11:51 -0700, Sarah Sharp wrote: > > On Wed, Aug 17, 2011 at 06:01:39PM +0800, Andiry Xu wrote: > The host can not stop the endpoints without suspend bit when the device > is in U2 state. But I doubt if it's a hardware bug. For a USB 2.0 device to be in L1, does the endpoint ring have to be empty? Or can the hardware automatically put it in L1 after so many NAKs? If an endpoint ring can have a TD on it when a USB 2.0 device is in L1, and your host controller doesn't respond to a stop endpoint command when the device is in L1, then I think we have an issue. I'm also concerned about a USB 3.0 device being in U1 or U2. Since USB 3.0 devices can drive themselves into U-states, there is the possibility that the device will be U1/U2 when the ring has one or more TDs on it. The issue is with cancellation. The host controller *must* send a successful stop endpoint command event when the device is in L1/U1/U2 in order for cancellation to work. Otherwise the stop endpoint command will time out and the command watchdog timer will fire. Then the xHCI driver will think the host controller is dying, halt and reset it, and call usb_hcd_died(). So if a USB 2.0 device's endpoint ring must be empty for it to be in L1, we're fine on that side. But I'm concerned that when we get around to implementing USB 3.0 LPM, we'll have issues if your host controller cannot respond to the stop endpoint command when the device is in U1/U2. > > > So only stop the endpoints if device is in U0 state. > > > > This doesn't seem right. If the USB core wants to put the device into > > suspend, the xHCI driver should turn off automatic link PM for that > > port, bring the device into U0, and then drive the port into U3. When > > the device resumes, the xHCI driver can re-enable LPM. > > > > Device suspend is always going to be a deeper power savings than either > > LPM state, so we want the device in U3 when the core asks for it to be > > in U3. I think we also want the device to be U3 for the case where > > the system is suspending, and we want to enable remote wakeup from USB > > devices. > > > > I don't quite get you. The port is in U2 when system wants to suspend, > and driver wants to put the port into U3. Do you mean driver needs to > resume the port into U0 first and then put it into U3? Why? It can enter > U3 from U2 directly. There is a spec ambiguity in this area. I think the USB bus spec says directly going from L1 to U3 is possible for a USB 2.0 device, but the xHCI spec's port state machines do not show that transition. If you look at the USB 2.0 port state machine in section 4.19.1.1.6 in the xHCI 1.0 spec, you'll notice there's no direct U2 to U3 transition. There's the same argument on the USB 3.0 LPM side. The software folks all think you can go from U2 to U3 in one state transition, but if you look at figure 7-13 in the USB 3.0 bus spec, you'll see there is no direct transition from U2 to U3. Figure 38 in the xHCI spec also has no direct U2 to U3 transition. That's why I think you need to have the port in U0 to successfully place it in U3. Even if transitioning it directly from U2 to U3 works on one host controller, there's no guarantee that it will work on another host controller. > It just does not respond to stop endpoint command. > And if a device is in U2 state, do we need to stop its endpoints? If any > endpoint is running, it can not be in U2 state. Is there anything in the spec that requires that? See my first questions. 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
