次の表は /sys/power/state (kernel 内対応関数 state_store()) に書き込む文字列と kernel の挙動です。PC (パソコン) で調査したのでアーキテクチャやプラット・ホームの機能で詳細な挙動に違いがあるかもしれません。関連ドキュメントは /Documentation/power/states.txt です。
書き込む文字列 (kernel 内定数) | プロセス稼働 | CPU稼働 | 主記憶内容 | 電力管理 | ACPI 相当 | 主要な dev_pm_ops call back[1] |
freeze (PM_SUSPEND_FREEZE) | 停止 | 継続 (idle 状態が長くなる) | 保持 | 周辺 IO デバイス 低消費電力化 | S0 | susped - (wake up) - resume |
standby (PM_SUSPEND_STANDBY) | 停止 | boot processor は最小限の内部状態を維持して停止[2]、それ以外の processor は内部状態を失って offline。復帰過程では boot processor が復帰後、その他の processor を online にしている | 保持 | 周辺 IO デバイス + CPU とその周辺 + 主記憶 低消費電力化 | S1 | susped - (wake up) - resume |
mem (PM_SUSPEND_MEM) | 停止 | boot processor は内部状態が待避されて停止[3]、それ以外の processor は内部状態を失って offline (全停止に至る過程で boot processor 以外を offline にしている。復帰過程も boot processor 復帰後、その他の processor を online にしている) | 保持 | 周辺 IO デバイス + CPU とその周辺 + 主記憶 低消費電力化 (standby よりも多くの復帰操作が必要な積極的な低消費電力化) | S3 | susped - (wake up) - resume |
disk (PM_SUSPEND_MAX) | 停止 | 内部状態を失って全停止 (全停止に至る過程で boot processor 以外を offline にして hibernation image 作成、online にして hibernation image を swap 領域へ書き出している) | swap 領域へ待避した後、喪失 | wakeup に必要な回路以外は電源 off | S4 | freeze - (hibernation image 作成) - thaw - (hibernation image 書き出し) - poweroff - (power_down) - (wake up) - restore |
[1] call back のうち prepare, complete, *_early, *_late, *_noirq, runtime_* は省略してあります。
[2] CPU に電源が供給されています。CPU 内部の詳細は公開されていないので推測するしか無いのですが、スタティック動作の回路は状態を維持します。ダイナミック動作の回路は状態を失い、PLL の様な clock 供給・分配系の回路は停止すると考えられます。
[3] 一般的に専用のハードウエアが processor の内部状態を待避復旧しています。このような専用のハードウエアは簡易なプロセッサとプログラムの組み合わせで構成されることもあります。
state ノードに "freeze" を書き込むと単に process が停止し device が suspend するのに対し、kernel 内の dev_pm_ops の freeze メンバ(call back pointer) は "disk" を書き込み hibernate (swap 領域にメモリ内容を書き出し電源 off) する時に呼ばれます。注意が必要です。
suspend - resume が上手くいかない場合
debugfs が /sys/kernel/debug に mount されているならば、# cat /sys/kernel/debug/suspend_stats (kernel 内対応関数 suspend_stats_show(), # cat /sys/kernel/debug/wakeup_sources (kernel 内対応関数 wakeup_sources_stats_show()) で suspend, resume, freeze 周辺の問題の要約を表示できます。/Documentation/power/basic-pm-debugging.txt にテストとデバッグの方法が書かれています。
dump_stack() を使って dev_pm_ops メンバが指している call back 関数が呼ばれるまでの call path を列挙します。i8253_ref ドライバを修正して取得しました。 platform_device 以外の device では途中から call path が変化します。