Re: So, what's the status on the recent patches here?

[Alan Stern <stern@rowland.harvard.edu>]

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