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

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

[Woodruff, Richard]

> > > No, it is because USB enabled prevents cpu from sleeping; it is
> > > actually well known.
> >
> > I vaguely recall hearing the why.  It has some DMAs which are going
on
> > and I suppose the processor must service the completions.
> > Now, if you coordinated with the USB device some how, you could try
> > > and
> 
> If I coordinated with USB device somehow, I'd know when it is possible
> to shutoff usb bus. This can be done locally at usb driver, no need
> for big framework. Just someone needs to write that code.

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

Now, programming up millions of combinations is not feasible.  However
you can profile your usage and target common use cases.  Playing MP3 and
reading a document for instance.

Thanks,
Richard W.

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

[Alan Stern]

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

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

[Pavel Machek]

Hi!

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

Are there some patches to test? I'd like to power down USB bus, even
when it has device connected (I do not user fingerprint scanner that
much).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Alan Stern]

On Fri, 25 Aug 2006, Pavel Machek wrote:

> Hi!
> 
> > > 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
> 
> Are there some patches to test? I'd like to power down USB bus, even
> when it has device connected (I do not user fingerprint scanner that
> much).

There are some old patches.  I could update them to the current -mm kernel 
and post them next week.

The idea of the patches is that they will autosuspend a USB hub when it
has no active (i.e., unsuspended) children, and autosuspending a root hub
stops the USB controller from doing DMA.  However, non-hub devices are not
yet automatically suspended, so you will have to suspend the fingerprint
scanner by hand.

Alan Stern

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

[Pavel Machek]

Hi!

> > Are there some patches to test? I'd like to power down USB bus, even
> > when it has device connected (I do not user fingerprint scanner that
> > much).
> 
> There are some old patches.  I could update them to the current -mm kernel 
> and post them next week.

Yes, that would be great.

> The idea of the patches is that they will autosuspend a USB hub when it
> has no active (i.e., unsuspended) children, and autosuspending a root hub
> stops the USB controller from doing DMA.  However, non-hub devices are not
> yet automatically suspended, so you will have to suspend the fingerprint
> scanner by hand.

That is okay, I can do that. It saves 2 hours of battery life on my
machine...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Alan Stern]

On Sat, 26 Aug 2006, Pavel Machek wrote:

> Hi!
> 
> > > Are there some patches to test? I'd like to power down USB bus, even
> > > when it has device connected (I do not user fingerprint scanner that
> > > much).
> > 
> > There are some old patches.  I could update them to the current -mm kernel 
> > and post them next week.
> 
> Yes, that would be great.
> 
> > The idea of the patches is that they will autosuspend a USB hub when it
> > has no active (i.e., unsuspended) children, and autosuspending a root hub
> > stops the USB controller from doing DMA.  However, non-hub devices are not
> > yet automatically suspended, so you will have to suspend the fingerprint
> > scanner by hand.
> 
> That is okay, I can do that. It saves 2 hours of battery life on my
> machine...

Come to think of it, you don't need the autosuspend patches to turn these 
devices off.  You can do it right now with your existing kernel, although 
it's a little easier with -mm.  (The reason is that -mm contains a 
development patch which ties a USB device's interfaces to the device 
itself; suspending the device will automatically suspend all its 
interfaces, and likewise resuming the device will automatically resume all 
its interfaces.  With a vanilla kernel you must manually suspend the 
interfaces before you can suspend the device and manually resume them 
after resuming the device.)

Anyway, you can use the deprecated 

	echo -n 2 >/sys/devices/.../power/state

mechanism to suspend all the USB interfaces, devices, and controllers you 
want -- provided you work your way up from the bottom of the device tree.  
The autosuspend patch just makes it simpler, since it takes care of 
suspending and resuming all the hubs for you.

Alan Stern

usb suspend (was Re: So, what's the status on the recent patches here?)

[Pavel Machek]

Hi!

> > > The idea of the patches is that they will autosuspend a USB hub when it
> > > has no active (i.e., unsuspended) children, and autosuspending a root hub
> > > stops the USB controller from doing DMA.  However, non-hub devices are not
> > > yet automatically suspended, so you will have to suspend the fingerprint
> > > scanner by hand.
> > 
> > That is okay, I can do that. It saves 2 hours of battery life on my
> > machine...
> 
> Come to think of it, you don't need the autosuspend patches to turn these 
> devices off.  You can do it right now with your existing kernel, although 
> it's a little easier with -mm.  (The reason is that -mm contains a 
> development patch which ties a USB device's interfaces to the device 
> itself; suspending the device will automatically suspend all its 
> interfaces, and likewise resuming the device will automatically resume all 
> its interfaces.  With a vanilla kernel you must manually suspend the 
> interfaces before you can suspend the device and manually resume them 
> after resuming the device.)
> 
> Anyway, you can use the deprecated 
> 
> 	echo -n 2 >/sys/devices/.../power/state
> 
> mechanism to suspend all the USB interfaces, devices, and controllers you 
> want -- provided you work your way up from the bottom of the device tree.  
> The autosuspend patch just makes it simpler, since it takes care of 
> suspending and resuming all the hubs for you.

Thanks! That works great and gets my power consumption into reasonable
range.. plus allows fan to actually stop.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html