Re: [RFD] Automatic suspend

[Alan Stern]

On Tue, 17 Feb 2009, Rafael J. Wysocki wrote:

> Phase 1: I agree that system-auto-suspend-on, system-auto-suspend-off would be
> useful, but I don't like the wakelocks interface.  Do you think there is an
> alternative way/mechanism of doing this?

I rather like the suggestions Matthew Garrett has been making.  They 
show how to improve the wakelock interface without losing any function.

Really, the idea behind wakelocks comes down to the question of how to
determine when the system is sufficiently idle to go into auto-suspend.  
There may be occasions when no task is runnable but userspace knows
that the system should not go to sleep because some work will be done
in the near future.  (Arve's example of a non-empty input buffer is
such a case.)  How should userspace let the kernel know whether it's
okay to suspend at these times?  That is the problem userspace
wakelocks are meant to solve.

Kernel wakelocks are a separate matter.  They are more like a form of 
optimization, preventing the kernel from starting an auto-suspend when 
some driver knows beforehand that it will return -EBUSY.

> Phase 3: Probably explicit control left to open/close.

While that's generally a good idea, it's important to recognize that 
some devices should be runtime-suspended even while they are open.  
Basically, any device that is "always open" falls in this category.  
Some examples are the screen, the keyboard, the mouse, and disk drives.  
And of course, some of these things already have runtime power 
management.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/