kernel-power-management

 There

are two types of power management that the operating system must handle: 

Device Power Management and,

System Power Management.


Device power management is an alias for the so-called Runtime Power Management. This may allow, among other things, part of the device not currently in use to be turned off in order to conserve

power, such as the keyboard backlight when you are not typing.


System Power Management, also known as Sleep States: This enables platforms to enter a system-wide low-power state.



dynamic power management interfaces:

CPU Idle: Whenever a logical CPU in the system has no task to execute, it may need to be put in a

particular state in order to save power. In this situation, most operating systems simply

schedule a so-called idle thread. While executing this thread, the CPU is said to be idle,

or in an idle state. CPU Idle is a framework that manages idle threads. There are several

levels (or modes or states) of idling. It depends on the built-in power-saving hardware

embedded in the CPU. CPU idle modes are sometimes referred to as C-modes or even

C-states, which is an Advanced Configuration and Power Interface (ACPI) term.

ARM platforms only provide one or two idle states. The choice of the state to enter is based on policies managed by

governors. A governor in this context is a simple module implementing an algorithm enabling

the best C-state choice to be made, depending on some properties.

/sys/devices/system/cpu/cpu0/cpuidle/

C-state /sys/devices/system/cpu/cpuidle/current_governor_ro

hotplug /sys/devices/system/cpu/cpu2/online


CPUFreq: CPUfreq or dynamic voltage and frequency scaling (DVFS)  This framework allows dynamic voltage selection and frequency scaling for the CPU,

based on constraints and requirements, user preferences, or other factors. Because this

framework deals with frequency, it unconditionally involves a clock framework. This

framework uses the concept of Operating Performance Points (OPPs), which consists of

representing the performance state of a system with {Frequency,voltage} tuples.

CPUfreq also uses the concept of governors

ondemand, conservative, performance, powersave, schedutil etc

/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors



Thermal:This framework is dedicated to monitoring the system temperature. It has dedicated

profiles according to temperature thresholds. The thermal framework uses the following concepts:

Thermal zones, Thermal sensors, Cooling devices, Trip points, 

/sys/class/thermal/




System power management sleep states

cat /sys/power/states

Suspend to idle (freeze): This is the most basic and lightweight. This state is purely software driven and involves

keeping the CPUs in their deepest idle state as much as possible. To achieve this, the user

space is frozen (all user space tasks are) and all I/O devices are put into low-power states

echo freeze > /sys/power/state


Power-on standby (standby or power-on suspend): In addition to freezing the user space and putting all I/O devices into a low-power state,

another action performed by this state is to power off all non-boot CPUs. resume latency will generally be greater than for the

freeze state,

echo standby > /sys/power/state


Suspend-to-ram (suspend, or mem): this state goes further by powering off all CPUs and putting the memory into self-refresh so that its

contents are not lost, although additional operations may take place depending on the

platform’s capabilities. Response latency is higher than standby, yet still quite low. In this

state, the system and device state is saved and kept in memory. This is the reason why only

the RAM is fully operational

echo mem > /sys/power/state



Powe management is facilitated by the kernel providing the struct dev_pm_ops that each device driver/class/bus interested in power management must fill. This

allows the kernel to communicate with every device in the system


struct dev_pm_ops {

int (*prepare)(struct device *dev);

void (*complete)(struct device *dev);

int (*suspend)(struct device *dev);

int (*resume)(struct device *dev);

int (*freeze)(struct device *dev);

....

}:



-------------------------------------------------------------------

Some good linkes for different power management blog

Linux PSCI framework

https://www.cnblogs.com/LoyenWang/p/11370557.html


Suspend process analysis

https://www.cnblogs.com/LoyenWang/p/11372679.html


cpuidle framework

https://www.cnblogs.com/LoyenWang/p/11379937.html


cpufreq framework

https://www.cnblogs.com/LoyenWang/p/11385811.html












runtime PM capability



system power management capability



S2R


In a DRAM chip, each bit of memory data is stored as the presence or absence of an electric charge on a small capacitor on the chip.[2][3] As time passes, the charges in the memory cells leak away, 

so without being refreshed the stored data would eventually be lost. To prevent this, external circuitry periodically reads each cell and rewrites it, restoring the charge on the capacitor to its original level. 

Each memory refresh cycle refreshes a succeeding area of memory cells, thus repeatedly refreshing all the cells in a consecutive cycle. This process is typically conducted automatically in the background by the memory circuitry and is transparent to the user.[2] 

Comments

Popular posts from this blog

dev_get_platdata understanding

Getting started with pinctrl subsystem linux

How to take systrace in android