On Tuesday 26 April 2005 10:08 am, Alan Stern wrote: > On Tue, 26 Apr 2005, Olav Kongas wrote: > > > Also, remote wakeups can result in resuming of root hub only > > if device is not suspended. Was that correct?
No; remote wakeup wakes up the device that was suspended plus any parent devices that were suspended. If the device wasn't suspended, then it can't be woken up... > It depends. If the device supports some form of remote wakeup, then it > might be possible to wake up both the device and the root hub. However at > the moment Linux doesn't have good support for remote wakeup when the > system as a whole isn't asleep. To make matters worse, device wakeup is > very platform-specific. So for example, with PCI right now you are right. Actually that's 180 degrees around from how I'd put it: - USB remote wakeup (with CONFIG_USB_SUSPEND) has _only_ really been tested apart from system sleep states. And for PCI, in particular, it's been tested with EHCI and OHCI root hubs (but not host controllers!!) suspended ... since, unlike SOC systems, PCI uses out-of-band signaling for device wakeup. - Wakeup _in general_ doesn't play well with system sleep states, especially with lots of swsusp-oriented changes tuning things for power-off states that, often as not, won't leave systems powered up enough that wakeup can work. That's actually a very useful intermediate state to work with, since for example suspending a tree of USB devices will let their HCD stop DMA accesses, which lets most systems reduce power. X86 hardware can only enter C3 (and C4?) CPU states when there's no regular DMA action, because the CPUs do cache snooping. For SOC systems, turning off the 48 MHz USB clock (by suspending the host or peripheral controller) is usually a prerequsite for entering lower power states. > > I haven't fully understood the intended relationship between > > device's and root hub's suspend/resume operations. The > > reason why root hub's suspend/resume are currently called > > from device's suspend/resume in isp116x-hcd was exactly to > > avoid this explicit double suspending/resuming via sysfs. > > Don't forget the world outside of USB! As far as I know there aren't any > other parts of the kernel where suspending/resuming a device will > automatically suspend/resume the children/parent. Why should USB be any > different? In the grand-and-glorious future when the device PM core has sane behavior for those sysfs operations, it won't be. Operative word: "future". - Dave ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
