On Wed, 2011-08-31 at 00:27 +0800, Sarah Sharp wrote: > 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. > >From my observation, the ep rings are empty when the device is in U2 state. But seems spec does not guarantee that. > > > > 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. > OK, according to the state machine figure, it appears a port can not transition from U2 to U3 directly. So I think the driver should work like this: When driver wants to put the port into U3: disable hardware LPM if it's enabled; resume the port to U0 if it's in U1/U2; stop its endpoints; put the port into U3. And when resume the port from U3 to U0, enable hardware LPM again. Is that acceptable? Thanks, Andiry -- 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
