Another thing that Kevin is missing: There is more to the system than
the devices and the CPU.  For example: RAM, an embedded controller (on
modern desktop/laptop systems), a power supply, and so on.  Dynamic PM
for the CPU and the devices won't power-down these things, but system
PM will.

Alan Stern

--

[ message continues ]

In an embedded system I'd expect that these other system devices would
fall naturally out through the management of the CPUs and devices - for
example, the drivers for the individual devices could use the regulator
API to manage their supplies and runtime PM is being used to manage CPU
core stuff - or could at least readily be handled in a similar fashion.

This isn't to say that we're there yet from an implementation point of
view, of course.
--

[ message continues ]

I consider all of those things devices.

On non-ACPI systems where the kernel has to manage all of the above
directly, we have drivers for all of them using runtime PM as well as
the regulator framework for dynamic PM power supplies.

Kevin
--

[ message continues ]

Somewhat true - machines with C1E support will put the RAM into self 
refresh when the cpu is idle, but you're right that there are various 
components that we simply don't have control over in the desktop world 
at present.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

As a contrast, at least on some embedded SoCs without firmware
limitations the low level sleep code for Runtime PM / CPU Idle is
shared with system wide suspend. So the RAM is put into self refresh
regardless of entering a half-deep CPU Idle state or entering
suspend-to-memory.

I've heard that newer SH-Mobile ARM hardware monitors the memory bus
activity behind the scenes and can put the system RAM into self
refresh automatically. On older parts we had to manage that from CPU
idle context.

/ magnus
--

[ message continues ]