On Tue, 16 Oct 2012, Sarah Sharp wrote: > > The kernel support we have now for USB-2 LPM doesn't make any sense. > > usb_port_suspend() disables LPM before changing the link state out of > > L0, and usb_port_resume() enables LPM after changing the state back to > > L0. > > > > Thus LPM is disabled precisely at the times when it might be useful! > > One thing to understand is that the USB 2.1 LPM code is designed to only > take advantage of host controllers that can do hardware-controlled LPM. Not so. At least, not in the two documents that are part of the USB-2 zip archive currently available from www.usb.org. They make no mention of automatic power-level changes; everything has to be initiated by the host OS (except for device-initiated wakeup). > It also only works for devices directly attached to the roothub. The > code expects that once LPM is enabled, the host controller will > automatically put the idle link into L1 after the port L1 timeout > expires. Where is this hardware-controlled LPM documented? And the port L1 timeout? Are you referring to section 4.23.5.1.1.1 in the xHCI spec? It doesn't apply to USB-2 hosts or hubs. > > In addition to this, I see that ehci-hcd includes some basic support > > for LPM but it doesn't implement the set_usb2_hw_lpm HCD method. It's > > a sort of do-it-yourself approach (and it includes a bunch of bugs). > > Yeah, I think Jacob Pan and another OTC person worked on the USB 2.1 LPM > for an Intel SoC board, but they never found very many USB 2.1 devices, > so they couldn't test it very well. Maybe that's an indication we shouldn't bother to support it. What do you think? I could take it out of ehci-hcd easily enough. > > One thing I didn't understand; maybe you can explain where to look. > > The USB 2.0 LPM ECN describes a specific kind of control transfer used > > for enabling LPM transitions for devices attached to hubs. Section > > 4.10.3 says that bRequest should be set to SET_AND_TEST -- but the > > document doesn't define SET_AND_TEST anywhere. Do you know where it is > > defined? > > Did you look for errrata associated with the USB 2.0 ECN? Since the > xHCI host provides registers for placing the device into L1, I never > really had to look the bus-level mechanism to do so. Sure enough, it's in the errata document. That document was added just about a year ago, and I haven't checked for updates in longer than that... > > P.S.: Going back to an earlier topic of conversation... > > > > There is a good reason for treating the FREEZE and QUIESCE (or PRETHAW) > > events differently from the others, although I may have forgotten to > > mention it. The other events involve changing power levels, but these > > two don't. They require only that devices be quiescent: not generating > > IRQs or doing DMA. Since USB devices (as opposed to host controller) > > can't do either, FREEZE and QUIESCE are no-ops for them. > > > > With OHCI and UHCI, there's no way to stop the controller from doing > > DMA while still sending SOF packets over the USB bus. Therefore > > quiescing the root hub amounts to the same thing as doing a bus > > suspend, and we haven't tried to distinguish the two operations. They > > both end up calling hcd_bus_suspend(). > > > > EHCI hardware _is_ capable of turning off IRQs and DMA while keeping > > the bus alive. But ehci-hcd doesn't make use of this capability -- > > indeed, it has no way of doing so because both events go through the > > same ehci_bus_suspend() routine. > > > > I don't know about xHCI; can it also be quiesced while keeping the USB > > bus alive? If so, we should think about adding a pair of new HCD > > methods for FREEZE/QUIESCE and THAW/RECOVER. > > We could stop all endpoints, and halt the host controller, and I think > that should stop all DMA. The host controller developers *should* know > that the OS or BIOS could move structures around and rewrite registers > after the host is halted, but since there's no "you *shall* not DMA > after you are halted" sentence in the spec, who knows what hosts > actually do. Especially the ones that use scratchpad pages for internal > storage keeping. > > I think it's probably safer to just rely on the bus suspend methods we > already have to quiesce the host controller. That triggers the xHCI > save registers code. Host controllers expect to be powered down after > the registers are saved, so they shouldn't be doing any DMA after that > command completes. Okay. But that still leaves a question: Is it reasonable to call xhci-hcd's bus_suspend method without first putting all the devices on the bus into U3? If it is then generic_suspend() can avoid calling usb_port_suspend() for the FREEZE and PRETHAW events, even on a USB-3 bus. 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
