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

Woodruff, Richard
2006-08-25T20:57:15Z

> ? Wouldn't suspending the entire bus completely stop the throughput
of
> any attached device?

Not necessarily (right?). If I shut off VBUS then yes then I need to
re-enumerate for sure. One might figure out a cleaver way of shutting
it off and turning it back on in between host requests. If I have a USB
drive attached it might well be the protocol layers are smart enough
keep using the device once it is restarted at the low layers. They just
have to wait longer for the data to arrive.

If I just do USB bus suspend the device at the other end can signal
remote wake up to me. I tell him suspend and he agrees to drop to a low
power state, then I lower current capacity. When he has some data he
can let me know and I'll up the VBUS current capacity and then go talk
to him. If I have data I want from him I directly wake him up.

In both cases the extra overhead causes my throughput to drop, but I
still have an effective connection to the device.

At the PM summit Len made a nice observation that you can map all the
processor ACPI-States right to devices. You can have T states with them
if you 'throttle' them (slow down their clock). You can have P states
with voltage/frequency changes. And you can have C-states (1,2,3) by
shutting down devices in-between accesses, etc. You can likely have a
single state representation which covers processors and devices. You
might even implement 'race to idle' conditions at the devices. Get the
work done then shut off to as low a state as you can and still have
acceptable latency. This was what sparked the 'on-ness' discussion a
while back on this list.

> > 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.

That seems possible.

> 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.

Applying an activity time of sorts to each driver 'might' end up in
situations where you get good power savings. Assuming everything lines
up. However, given hardware and software bugs and errata, it seems
forcing the situation is much more likely to succeed and make sure you
hit your targets.

Even with a per-driver activity timer how does one set the time out
levels for the whole system? You need some kind of policy pieces to set
all the knobs. Letting the self adjust won't likely work for QOS
(quality of service type things) unless they are set very
conservatively.

Thanks,
Richard W.