On Fri, 25 Aug 2006, Woodruff, Richard wrote: > There are two sides to this in the case for the embedded processor I'm > using. > > -A- you have to put the USB bus into suspend mode. > - This will lower the throughput of the device on the other end. ? Wouldn't suspending the entire bus completely stop the throughput of any attached device? > The frequency of entering this state should not interfere with my active > use case. > > -B- After I've put down the USB device, I now can program the internal > SOC bus wrapper for the USB to allow idling of the interconnect. I also > need to associate the USB remote wake interrupt with a wake up interrupt > to restart my interconnect. All devices on that interconnect must be in > the same state for the big savings to happen. > > Certainly for this embedded system, not coordinating the device states > means I can't get the big power savings. Part of this programming has to be done in the architecture-specific driver for the interconnect. There already is code being developed to suspend USB buses when they aren't in use (although determining _when_ they aren't in use has not yet been implemented). However this code stops at the level of the USB controller. Further development is being stymied by lack of information about how to detect the controller's wake-up events on regular desktop systems; it's possible someone might implement this first on an embedded platform. But this doesn't require any over-reaching global coordination. All it needs is for each driver to know when it's not being used. Alan Stern
