PATCH/RFC: driver model/pmcore wakeup hooks (0/4)

PATCH/RFC: driver model/pmcore wakeup hooks (0/4)

[David Brownell]

There's been some discussion about limitations of the current
pmcore for systems that want to be partially suspended most
of the time.  That is, where the power management needs to
affect ACPI G0 states, not G1 states like S1/S3/S4, and isn't cpufreq.

One significant example involves USB mice.  If they were to be
suspended (usb_suspend_device) after a few seconds of inactivity,
that change could often spread up the device tree and let the
USB host controller stop DMA access.  Some x86 CPUs could
then enter C3 and save a couple Watts of battery power ... until
the mouse moved, and woke that branch of the device tree
for a while (until the mouse went idle again).

Most of the parts for that are now in place.  But trying to use
them will turn up places where the pieces don't fit together
very well yet ... and wakeup support is one of them!  So for
example it's not possible to disable such an autosuspend
mechanism for mice that can't actually issue wakeups.

So here are a few patches that add some driver model support
for wakeup capabilities, and use it for PCI and USB.

 - wake-core.patch, adds two bits and sysfs control over one of them
 - wake-pci.patch, makes pci use those bits
 - wake-usbcore.patch, makes usb do so (replacing code/hacks)
 - wake-ohci.patch, matching wake-usbcore

The patches follow this, going to LKML.

Comments?

- Dave

Re: PATCH/RFC: driver model/pmcore wakeup hooks (0/4)

[Pavel Machek]

Hi!

> One significant example involves USB mice.  If they were to be
> suspended (usb_suspend_device) after a few seconds of inactivity,
> that change could often spread up the device tree and let the
> USB host controller stop DMA access.  Some x86 CPUs could
> then enter C3 and save a couple Watts of battery power ... until
> the mouse moved, and woke that branch of the device tree
> for a while (until the mouse went idle again).


How fast is the wakeup? Will not that make mouse jump a bit? (Just curious...)
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: PATCH/RFC: driver model/pmcore wakeup hooks (0/4)

[David Brownell]

On Tuesday 05 October 2004 12:32 pm, Pavel Machek wrote:
> Hi!
> 
> > One significant example involves USB mice.  If they were to be
> > suspended (usb_suspend_device) after a few seconds of inactivity,
> > that change could often spread up the device tree and let the
> > USB host controller stop DMA access.  Some x86 CPUs could
> > then enter C3 and save a couple Watts of battery power ... until
> > the mouse moved, and woke that branch of the device tree
> > for a while (until the mouse went idle again).
> 
> 
> How fast is the wakeup? 

30+msec for the USB-specific signaling; plus a bit more for each
layer of USB hubs in its tree.  Lots more if power glitches force
re-enumeration of anything; but if those happen, they'd happen
during normal use too.


> Will not that make mouse jump a bit? 
> (Just curious...) 

I actually don't have a wakeup-capable mouse (the one I
have lies about it, fwiw) so I don't know how that acts.
My current wakeup testing uses a USB keyboard instead.

It may even need to be a click that wakes up the mouse;
you don't much want the system to wake up if you nudge
the table (and hence mouse), or a truck goes by, etc.

Len Brown may have details, he was particularly keen
on having this scenario work, given the number of Intel
laptops that would last longer under Linux this way ... it
was evidently a big win under Windows.

- Dave