Re: [PATCH] implement pm_ops.valid for everybody

[David Brownell <david-b@pacbell.net>]

On Wednesday 21 March 2007 2:01 pm, Guennadi Liakhovetski wrote:
> On Tue, 20 Mar 2007, David Brownell wrote:
> > 
> > By the way ... as a note to implementors, it should be trivial to
> > implement a basic "standby" state that suspends drivers, disables
> > many clocks, and probably puts DRAM into self-refresh mode, but
> > uses only the wait-for-interrupt CPU lowpower mode.
> > 
> > A key difference between that and STR would then be that STR does
> > extra magic, like switching the CPU to a slow clock and then turning
> > off all the clocks that drive the chip "fast".  Also, that because
> > it disables so many clocks, the SOC probably can't support as many
> > types of wakeup events in STR.
> 
> Hm, interesting. What you described above is very similar to what I've 
> just implemented for a 8241 based system (linkstation: 
> http://ozlabs.org/pipermail/linuxppc-dev/2007-March/thread.html#33203).

Just the other day.  :)


> But Paul Mackerras suggested to consider it a StR, whereas Johannes Berg 
> proposed to call it a standby, which is also what seems to be more logical 
> to me. 

Seems more like a "standby" to me too -- at least by comparison to
APM and ACPI definitions of "standby", vs what STR involves.


> May we agree on some "simple" criteria, like "CPU power on, i.e.,  
> CPU registers preserved"? If yes - standby, CPU off, registers lost - StR? 

The ACPI spec has some verbiage on those things, which uses
roughly that distinction.

Which is very much an indication of how weak ACPI is.  It
doesn't contemplate typical SOC behavior, which have a wide
variety of system sleep states that leave the CPU on ... and
which may not even *have* (or need!) a "cpu off" state.

My own definition would be more like:  the minimal RAM-based
power-saving system state is "standby".  If the system
implements a deeper RAM-based system sleep state, that's "STR".

If Linux eventually allows more system sleep states than
just "standby", "mem", and "disk", then most of the new
states will probably fit between "standby" (ACPI S1) and
"mem" (ACPI S3).


> I can imagine CPUs with multiple power sources allowing to switch some of 
> them on and off respectively losing / keeping some register sets...

I can see that more readily with SOC designs that have multiple
power domains.  Consider:  CPU, Peripherals-1, Peripherals-2.
That implies several sleep states:

  - all domains powered
  - only peripherals-1 off
  - only peripherals-2 off
  - both peripheral domains off
  - ...
  - all three domains off

Now, I'm not sure that it would be useful to expose all those
states to userspace, but surely an implementor might find it
useful to implement more than one.  In which case, one would
be called "standby", the next "STR", and ... well, Linux PM
can't handle anything else yet.

- Dave