[linux-pm] [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

Sorry for being late to the party, I had more urgent things to take care of.

On Saturday 31 January 2009, Alan Stern wrote:
> On Fri, 30 Jan 2009, Brian Swetland wrote:
> 
> > [Alan Stern <stern at rowland.harvard.edu>]
> > > > > Does the wakelock mechanism distinguish between suspend or power-state
> > > > > transitions that happen automatically and transitions requested
> > > > > directly by userspace?
> > > > 
> > > > No.
> > > 
> > > And I think this is a big mistake.  It makes sense to have locks for
> > > blocking auto suspend, but it does not make sense to prevent the user
> > > from putting his own computer to sleep.
> > > 
> > > For example: Suppose some program happens to hold a wakelock, perhaps 
> > > because of a simple bug, when the user closes the laptop lid and throws 
> > > the laptop into a backpack.  We don't want the computer to remain awake 
> > > under those circumstances!
> > 
> > It depends on the particular "computer" and the problem you're solving.
> 
> I disagree.

Yeah.

However, I think that what we are used to call a sleep (or suspend) state is
really a power off state for cell phone people.  So lets define what we're
talking about.

Sleep states (suspend to RAM, hibernation) are the states of the whole system
in which no instructions are executed by the processor(s).  The difference
between a sleep state and the power off state is that in a sleep state we have
some application context saved (in memory or in a storage device) and
(in principle) after the system goes back to the working state, the
applications can continue doing do whatever they had been doing before the
system was put into the sleep state.

If instructions are executed by the processor(s), the system is in the working
state.

> > Imagine the computer in question is a cellphone which is going to need
> > to wake up when a call comes in to do traditional cellphone things, like
> > ring, bring up the incall UI (so the user can answer/cancel), etc.
> 
> Yes.  So what?  Nothing I said prevents the computer from waking up 
> when a call comes in.  What I said was that when the user tells the 
> computer to suspend (e.g., by writing "mem" to /sys/power/state), the 
> computer should suspend even if some wakelocks are still locked.

Agreed.

There should be well defined set of signals that can wake up the system
from the sleep state and the user should be able to control them.
 
> > Or perhaps it's an always-connected data device that might get remote
> > messages (IM notifications, contacts/email sync, etc) over the network
> > while it's "asleep" that need some processing.
> 
> By "asleep", do you mean something other than suspended?  If you do 
> then you have misunderstood me.  I'm talking about a true suspend -- 
> that is, the suspend routines in drivers/base/power/main.c have run, 
> everything is in a low-power state or turned off, and the CPU isn't 
> running.
> 
> Obviously the computer can't do any processing when it is suspended.  
> The only thing it can do is resume.  And a resume can be initiated by a
> wide variety of signals, including such things as receipt of a network 
> packet or a phone call.
> 
> > Bad usage of wakelocks can certainly lead to poor battery life, but
> > there are definitely situations where you might want to operate in a
> > mode where the user considers the device "asleep" but it may still wake
> > up to handle certain tasks.
> 
> I don't care what the user thinks; I care about what the kernel 
> actually does.  If the user wants to delude himself into thinking the 
> computer is "asleep" while the kernel is still running, that's his 
> problem.

Well, I think that sleep states are not really useful in cell phones.  Useful
is the ability to put all devices into low power states separately and as
needed (eg. after a period of inactivity).  IOW, the system as a whole is
in the working state, but some parts of the hardware may be in low power states
(even all of the I/O devices may be in low power states).  That may very well
look "asleep" from the user point of view, but it is not a sleep state.

Thanks,
Rafael