1. Hibernation In Linux 2.6.29
Author:
Varun Mahajan
<varunmahajan06@gmail.com>

2. Contents & References
 Scope of the Document
 Section 1
– ACPI Specification
– States defined by ACPI Specification
– System Power Management States
– Sysfs Interface
– Tasks: Freeze, Thaw
– Device Power Management
– Notifiers
– Memory Snapshot
 Section 2
– Hibernate Algorithm
– Resume Algorithm
 Section 3
– Android Wakelocks
 Section 4
– Appendix: Code Flow in Linux 2.6.29

3. Scope of the Document
This Document is divided into following 4 sections:
● Section 1 covers, in brief, the concepts required to understand
hibernate/resume implementation in Linux-2.6.29
● Section 2 explains the hibernate/resume algorithm that is implemented in
Linux-2.6.29. Understanding of the concepts explained in the first section is a
prerequisite to understand the algorithm
● Section 3 explains the Android Wakelock feature, which breaks the
/sys/power/state interface
● The Appendix explains the hibernate/resume code flow in Linux 2.6.29

4. ACPI Specification
The Advanced Configuration and Power Interface (ACPI) specification was
developed to establish industry common interfaces enabling robust operating
system (OS)-directed motherboard device configuration and power
management of both devices and entire systems. ACPI is the key element in
Operating System-directed configuration and Power Management (OSPM)
The interfaces and OSPM concepts defined within this specification are
suitable to all classes of computers including (but not limited to) desktop,
mobile, workstation, and server machines. From a power management
perspective, OSPM/ACPI promotes the concept that systems should conserve
energy by transitioning unused devices into lower power states including
placing the entire system in a low-power state (sleeping state) when possible.

5. States defined by ACPI Specification
Global Power States:
Global power states apply to the entire system and are visible to the user
 G0 Working: A state where the system dispatches user mode threads and
they execute. In this state peripheral devices are having their power state
changed dynamically
G1 Sleeping: A state where the system consumes a small amount of power,
user mode threads are not being executed, and the system appears to be off.
Work can be resumed without rebooting the OS because large elements of
system context are saved by the h/w and rest by the system s/w
 G2/S5 Soft Off: A state where the system consumes a minimal amount of
power. No user mode or system code is run. The system's context will not be
preserved by the h/w. The system must be restarted to return to the working
state
 G3 Mechanical Off: A state that is entered and left by mechanical means
(turning off the system). The OS must be restarted to return to working state.
No h/w context is retained. Except for RTC, power consumption is zero

6. States defined by ACPI Specification
Sleeping State Definitions:
Sleeping states are types of sleeping states within the global sleeping state
G1
 S1: In this state no system context is lost (CPU or chip set) and h/w
maintains all system context
 S2: This state is similar to S1 except that the CPU and system cache context
is lost (the OS is responsible for maintaining the caches and CPU context).
Control starts from the processor’s reset vector after the wake event
 S3: CPU, cache, and chip set context are lost in this state. Hardware
maintains memory context and restores some CPU and L2 configuration
context. Control starts from the processor’s reset vector after the wake event
 S4: The S4 sleeping state is the lowest power state. In order to reduce
power to a minimum, it is assumed that the hardware platform has powered
off all devices. Platform context is maintained
S5 Soft Off: The S5 state is similar to the S4 state except that the OS does
not save any context. The system is in “soft” off state and requires a complete
boot when it wakes

7. States defined by ACPI Specification
Device Power States:
Device power states are states of particular devices; as such they are
generally not visible to he user
 D0: State in which device is on and running. It is receiving full power from
the system and is delivering full functionality to the user
D1: Class-specific low-power state in which the device context may or may
not be lost. Buses in D1 cannot do anything to the bus that would force the
devices on that bus to lose context (Many Device classes may not define D1)
 D2: Class-specific low-power state in which the device context may or may
not be lost. Attains greater power savings than D1. Buses in D2 can cause
devices on that bus to lose some context (e.g. the bus reduces power supplied
to the bus, thus forcing the device to turn off some of its functions). Devices in
D2 must be prepared for the bus to be in D2 or higher (Many Device classes
may not define D2)
 D3: State in which device is off and not running. Device context is lost.
Power can be removed from the device

8. System Power Management States
Standby/Power-On Suspend:
This state offers minimal, though real, power savings, while providing a very
low latency transition back to a working system. No operating state is lost (the
CPU retains power)
ACPI states mapping:
Sleeping state: S1
Device state: Devices which support D1 are put into D1. The ones which don't,
are left on

9. System Power Management States
Suspend-to-RAM
This state offers significant power savings as everything in the system is put
into a low-power state, except for memory, which is placed in self-refresh
mode to retain its contents
System and device state is saved and kept in memory
ACPI states mapping:
Sleeping state: S3
Device state: All devices are suspended and put into D3

10. System Power Management States
Suspend-to-Disk (Hibernation)
This state offers the greatest power savings. This state operates similarly to
Suspend-to-RAM, but includes a final step of writing memory contents to non-
volatile storage. On resume, this is read and memory is restored to its pre-
suspend state
For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap
Suspend) is used to write memory contents to free swap space. Once memory
state is written to disk, the system may either enter a low-power state (like
ACPI S4), or it may simply power down. Powering down offers greater savings,
and allows this mechanism to work on any system. However, entering a real
low-power state allows the user to trigger wake up events (e.g. pressing a key
or opening a laptop lid)
ACPI states mapping:
Sleeping state: S4
Device state: All devices are suspended and put into D3

11. System Power Management States

12. Sysfs Interface
The interface exists in /sys/power/ directory
/sys/power/state:
This controls the system power state
Reading from this file returns what states are supported:
 'standby': Power-on Suspend
 'mem': Suspend-to-RAM
 'disk': Suspend-to-Disk
Writing to this file one of these strings causes the system to transition into
that state

13. Sysfs Interface
/sys/power/disk:
This controls the operating mode of the Suspend-to-Disk mechanism
Operating modes:
 'platform': put the system to sleep using platform driver (ACPI)
 'shutdown': power off the system
 'reboot': reboot the system (for testing)
 'testproc': will cause the kernel to disable nonboot CPUs and freeze tasks,
wait for 5 seconds, unfreeze tasks and enable nonboot CPUs
 'test': will cause the kernel to disable nonboot CPUs and freeze tasks, shrink
memory, suspend devices, wait for 5 seconds, resume devices, unfreeze tasks
and enable nonboot CPUs
Reading from this file will display all supported modes and the currently
selected one in brackets
Writing one of the strings to this file will select the corresponding mode
When 'disk' is written to /sys/power/state the Suspend-to-Disk mechanism will
work according to the selected mode

14. Sysfs Interface
/sys/power/image_size:
This controls the size of the image created by the Suspend-to-Disk mechanism
It can be written a string representing a non-negative integer that will be used
as an upper limit of the image size, in bytes. The suspend-to-disk mechanism
will do its best to ensure the image size will not exceed that number.
However, if this turns out to be impossible, it will try to suspend anyway using
the smallest image possible. In particular, if "0" is written to this file, the
suspend image will be as small as possible
Reading from this file will display the current image size limit, which is set to
500 MB by default
/sys/power/resume:
Reading from this file will display the major:minor numbers of the swap
partition to be used for Suspend-to-Disk
Writing major:minor numbers to this file will cause the system to resume from
the mentioned partition

15. Tasks: Freeze, Thaw
The freezing of tasks is a mechanism by which user space processes and
some kernel threads are controlled during hibernation or system-wide
suspend. The tasks are frozen before the hibernation image is created and are
thawed after the system memory state has been restored from a hibernation
image and devices have been reinitialized
Relevant flags:
include/linux/shed.h:
 PF_NOFREEZE: this thread should not be frozen
 PF_FROZEN: frozen for system suspend
 PF_FREEZER_SKIP: Freezer should not count it as freezable
arch/arm/include/asm/thread_info.h
 TIF_FREEZE
The tasks that have PF_NOFREEZE unset (all user space processes and some
kernel threads) are regarded as 'freezable' and treated in a special way before
the system enters a suspend state as well as before a hibernation image is
created

16. Tasks: Freeze, Thaw
kernel/power/process.c, include/linux/freeze.h
Freeze:
freeze_processes():
It executes try_to_freeze_tasks() that sets TIF_FREEZE for all the freezable
tasks and either wakes them up, if they are kernel threads, or sends fake
signals to them if they are user space processes
A task that has TIF_FREEZE set should react to it by calling the function
refrigerator(), which sets the task's PF_FROZEN flag, changes its state to
TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
Then, we say that the task is 'frozen'
For user space processes try_to_freeze() is called automatically from the
signal-handling code, but the freezable kernel threads need to call it explicitly
in suitable places or use the wait_event_freezable() or
wait_event_freezable_timeout()

17. Tasks: Freeze, Thaw
Thaw:
thaw_processes():
It clears the PF_FROZEN flag for each frozen task. Then the tasks that have
been frozen leave the refrigerator() and continue running

18. Tasks: Freeze, Thaw
Why is freezing of tasks required:
 To prevent filesystems from being damaged after hibernation. The
hibernation image contains some filesystem-related information that must be
consistent with the state of the on-disk data and metadata after the system
memory state has been restored from the image (otherwise the filesystems
will be damaged in a nasty way). This is accomplished by freezing the tasks
that might cause the on-disk filesystems' data and metadata to be modified
after the hibernation image has been created and before the system is finally
powered off. The majority of these are user space processes, but if any of the
kernel threads may cause something like this to happen, they have to be
freezable
 To create the hibernation image a sufficient amount of memory
(approximately 50% of available RAM) needs to be freed before the devices
are deactivated. Then, after the memory for the image has been freed, we
don't want tasks to allocate additional memory and that is prevented by
freezing them earlier
To prevent user space processes and some kernel threads from interfering
with the suspending and resuming of devices

19. Device Power Management
System Sleep Model:
Drivers can enter low power states as part of entering system-wide low-power
states like Suspend-to-Ram, Suspend-to-Disk (hibernation)
This is something that device, bus, and class drivers collaborate on by
implementing various role-specific suspend and resume methods to
cleanly power down hardware and software subsystems, then reactivate them
without loss of data

20. Device Power Management
include/linux/device.h:
Bus Driver Methods:
The core methods to suspend and resume devices reside in struct bus_type.
Bus drivers implement those methods as appropriate for the hardware and the
drivers using it
struct bus_type {
...
int (*suspend)(struct device *dev, pm_message_t state);
int (*suspend_late)(struct device *dev, pm_message_t state);
int (*resume_early)(struct device *dev);
int (*resume)(struct device *dev);
struct dev_pm_ops *pm;
};

21. Device Power Management
Upper layers of driver stacks:
Device drivers generally have at least two interfaces, and the but_type
methods are the ones which apply to the lower level (bus hardware). The
network and block layers are examples of upper level interfaces, as is a
character device talking to userspace.
Power management requests normally need to flow through those upper
levels, which often use domain-oriented requests. In some cases those upper
levels will have power management intelligence that relates to end-user
activity, or other devices that work in cooperation.
For the upper level interfaces that are structured using class interfaces, there
is a standard way to have the upper layer stop issuing requests to a given
class device (and restart later)
struct class {
...
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
struct dev_pm_ops *pm;
};

22. Device Power Management
Device:
struct device {
...
struct device_type *type;
struct bus_type *bus;
struct class *class;
...
};
struct device_type {
...
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
struct dev_pm_ops *pm;
};

23. Device Power Management
include/linux/sysdev.h:
Sysdev:
struct sysdev_class {
…
struct list_head drivers;
int (*shutdown)(struct sys_device *);
int (*suspend)(struct sys_device *, pm_message_t state);
int (*resume)(struct sys_device *);
};
struct sysdev_driver {
...
int (*shutdown)(struct sys_device *);
int (*suspend)(struct sys_device *, pm_message_t state);
int (*resume)(struct sys_device *);
};
struct sys_device {
...
struct sysdev_class *cls;
};

24. Device Power Management
include/linux/pm.h:
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);
int (*thaw)(struct device *dev);
int (*poweroff)(struct device *dev);
int (*restore)(struct device *dev);
int (*suspend_noirq)(struct device *dev);
int (*resume_noirq)(struct device *dev);
int (*freeze_noirq)(struct device *dev);
int (*thaw_noirq)(struct device *dev);
int (*poweroff_noirq)(struct device *dev);
int (*restore_noirq)(struct device *dev);
};

25. Device Power Management
 prepare(): Prepare the device for the upcoming transition, but do NOT
change its hardware state. Prevent new children of the device from being
registered after prepare() returns (the driver's subsystem and generally the
rest of the kernel is supposed to prevent new calls to the probe method from
being made too once prepare() has succeeded)
 freeze(): Hibernation-specific, executed before creating a hibernation
image. Quiesce operations so that a consistent image can be created, but do
NOT otherwise put the device into a low power device state and do NOT emit
system wakeup events. Save in main memory the device settings to be used
by restore() during the subsequent resume from hibernation or by the
subsequent thaw(), if the creation of the image or the restoration of main
memory contents from it fails
 thaw(): Hibernation-specific, executed after creating a hibernation image
OR if the creation of the image fails. Also executed after a failing attempt to
restore the contents of main memory from such an image. Undo the changes
made by the preceding freeze(), so the device can be operated in the same
way as immediately before the call to freeze()

26. Device Power Management
 poweroff(): Hibernation-specific, executed after saving a hibernation
image. Quiesce the device, put it into a low power state appropriate for the
upcoming system state, and enable wakeup events as appropriate
 restore(): Hibernation-specific, executed after restoring the contents of
main memory from a hibernation image. Driver starts working again,
responding to hardware events and software requests
 complete(): Undo the changes made by prepare(). This method is
executed for all kinds of resume transitions, following one of the resume
callbacks: resume(), thaw(), restore(). Also called if the state transition fails
before the driver's suspend callback (suspend(), freeze(), poweroff()) can be
executed. The PM core executes complete() after it has executed the
appropriate resume callback for all devices
 freeze_noirq(), thaw_noirq(), poweroff_noirq(), restore_noirq():
Complete the operations of the corresponding function (freeze(), thaw(),
poweroff(), restore()) by carrying out any actions required for freezing the
device that need interrupts to be disabled

27. Device Power Management
Relevant P_EVENT_ messages:
 P_EVENT_FREEZE: System is going to hibernate, call prepare() and freeze()
for all devices
 P_EVENT_THAW: Hibernation image has been created, call thaw() and
complete() for all devices
P_EVENT_HIBERNATE: Hibernation image has been saved, call prepare() and
poweroff() for all devices
 P_EVENT_QUIESCE: Contents of main memory are going to be restored from
a (loaded) hibernation image, call prepare() and freeze() for all devices
 P_EVENT_RESTORE: Contents of main memory have been restored from a
hibernation image, call restore() and complete() for all devices

28. Notifiers
There are some operations that device drivers may want to carry out in their
suspend()/prepare() routines, but shouldn't, because they can cause the
hibernation or suspend to fail. For example, a driver may want to allocate a
substantial amount of memory (like 50 MB) in suspend()/prepare(), but that
shouldn't be done after the swsusp's memory shrinker has run. Also, there
may be some operations, that subsystems want to carry out before a
hibernation/suspend or after a restore/resume, requiring the system to be
fully functional
A Hibernation notifier may be used for this purpose. The subsystems that
have such needs can register suspend notifiers that will be called upon the
following events by the suspend core:
 PM_HIBERNATION_PREPARE: The system is going to hibernate or suspend,
tasks will be frozen immediately
 PM_POST_HIBERNATION: The system memory state has been restored from a
hibernation image or an error occurred during the hibernation. Device drivers'
resume()/restore() callbacks have been executed and tasks have been thawed

29. Notifiers
 PM_RESTORE_PREPARE: The system is going to restore a hibernation image.
If all goes well the restored kernel will issue a PM_POST_HIBERNATION
notification
PM_POST_RESTORE: An error occurred during the hibernation restore. Device
drivers' resume() callbacks have been executed and tasks have been thawed
 PM_SUSPEND_PREPARE: The system is preparing for a suspend
 PM_POST_SUSPEND: The system has just resumed or an error occurred
during the suspend. Device drivers' resume() callbacks have been executed
and tasks have been thawed

30. Memory Snapshot
The hibernation core 'snapshots' system memory by indexing and copying
every active page in the system. Once a snapshot is complete, the saved
image and index is stored persistently
The snapshot sequence is a three-step process. First, all of the active pages
are indexed, enough new pages are allocated to clone these pages, then each
page is copied into its clone
The snapshot process has one critical requirement: that at least half of the
memory be free. For this the memory needs to be freed before the snapshot
is taken. This is done using the memory shrinker

31. Hibernate
Execute
HIBERNATION_PREPARE Shutdown Machine
Notifiers
Save Hibernation Image
Sync File systems
Freeze Tasks
Suspend Devices Resume Devices
Free Requisite Memory
Take Non­boot CPUs Offline Enable Non­boot CPUs
Disable Interrupts on Main Enable Interrupts on Main
CPU CPU
Late Suspend Devices Early Resume Devices
Suspend System Devices Resume System Devices
Save Co­Processor and
Create Hibernation Image Restore Co­processor State
Processor States

32. Hibernate
 The power management notifiers registered for the event PM_HIBERNATION_PREPARE are
executed
All the filesystems are synced (Flush file system buffers, force changed blocks to disk, update the
superblock)
 Tasks are frozen
 The platform driver is informed that hibernation is being started
 The requisite memory to save the snapshot is freed using the memory shrinker
 The devices are suspended for the event P_EVENT_FREEZE. For each dev in dpm_list the following
are executed (in sequence): (dev->bus->pm, dev->type->pm, dev->class->pm)->prepare(), dev-
>class->pm->freeze() or dev->class->suspend(), dev->type->pm->freeze() or dev->type-
>suspend(), dev->bus->pm->freeze() or dev->bus->suspend()
 Machine is prepared for hibernation using the platform driver
 Non-boot CPUs are taken offline
 Interrupts are disabled on the main CPU
Late suspend of the devices (that require interrupts to be disabled) is carried out for the event
PM_EVENT_FREEZE. For each dev in dpm_list the following is executed: dev->bus->pm-
>freeze_noirq() or dev->bus->suspend_late()
 System devices are suspended for the event PM_EVENT_FREEZE. For each cls in system_kset->list
following is executed (in sequence): (For each drv in cls->drivers) ->suspend(), cls->suspend()
the

33. Hibernate
 Co-processor and the processor state is saved
 Atomic copy of the system memory (hibernation image) is created
 The co-processor state is restored
 System devices are resumed. For each cls in system_kset->list the following is executed (in
sequence): cls->resume(), (For each drv in cls->drivers) ->resume()
 Early resume of the devices is carried out for the event PM_EVENT_THAW. For each dev in dpm_list
the following is executed: dev->bus->pm->thaw_noirq() or dev->bus->resume_early()
 Interrupts are enabled on the main CPU
 Non-boot CPUs are enabled
 Machine is switched to normal mode mode of operation using platform driver
 The devices are resumed for the event P_EVENT_THAW. For each dev in dpm_list the following is
executed (in sequence): dev->bus->pm->thaw() or dev->bus->resume(), dev->type->pm->thaw()
or dev->type->resume(), dev->class->pm->thaw() or dev->class->resume(), (dev->class->pm,
dev->type->pm, dev->bus->pm)->complete()
 The platform driver is informed that the system has entered the working state
 Hibernation image is saved in the allocated swap partition
 Machine is shutdown

34. Resume
Probe of known Devices Proceed with the Current Execute
Kernel POST_HIBERNATION
Notifiers
Not OK
Check Resume Device and
swsusp Signature Freeze Tasks
Thaw Tasks
OK
Load hibernation Image to
Execute RAM
RESTORE_PREPARE
Notifiers
Suspend Devices Resume Devices
Take Non­boot CPUs Offline Enable Non­boot CPUs
Disable Interrupts on Main Enable Interrupts on Main
CPU CPU
Late Suspend Devices Early Resume Devices
Suspend System Devices Resume System Devices
Pass Control to Target
Kernel, Restore Processor Restore Co­Processor State
Save Co­Processor State
State to the one saved to the one saved

35. Resume
 Probing of the known devices is allowed to be finished before proceeding
 The swsusp signature is checked for in the resume device
 The power management notifiers registered for the event PM_RESTORE_PREPARE are executed
 Tasks are frozen
 Hibernation image is loaded into RAM
 The devices are suspended for the event P_EVENT_QUIESCE. For each dev in dpm_list the following
is executed (in sequence): (dev->bus->pm, dev->type->pm, dev->class->pm)->prepare(), dev-
>class->pm->freeze() or dev->class->suspend(), dev->type->pm->freeze() or dev->type-
>suspend(), dev->bus->pm->freeze() or dev->bus->suspend()
 The platform is prepared for restoration from a hibernation image
 Non-boot CPUs are taken offline
 Interrupts are disabled on the main CPU
Late suspend of the devices (that require interrupts to be disabled) is carried out for the event
PM_EVENT_QUIESCE. For each dev in dpm_list the following is executed: dev->bus->pm-
>freeze_noirq() or dev->bus->suspend_late()
 System devices are suspended for the event PM_EVENT_QUIESCE. For each cls in system_kset-
>list the following is executed (in sequence): (For each drv in cls->drivers)->suspend(), cls-
>suspend()

36. Resume
 Control is passed to the target kernel. This also restores the processor state
 Co-processor state is restored
 Machine is prepared for switching to normal mode of operation using the platform driver
 System devices are resumed. For each cls in system_kset->list the following is executed (in
sequence): cls->resume(), (For each drv in cls->drivers)->resume()
 Early resume of the devices is carried out for the event PM_EVENT_RESTORE. For each dev in
dpm_list the following is executed: dev->bus->pm->restore_noirq() or dev->bus->resume_early()
 Interrupts are enabled on the the main CPU
 Non-boot CPUs are enabled
 Machine is switched to normal mode of operation using the platform driver
The devices are resumed for the event P_EVENT_RESTORE. For each dev in dpm_list the following is
executed (in sequence): dev->bus->pm->restore() or dev->bus->resume(), dev->type->pm-
>restore() or dev->type->resume(), dev->class->pm->restore() or dev->class->resume(), (dev-
>class->pm, dev->type->pm, dev->bus->pm)->complete()
 The platform driver is informed that the system has entered the working state
 Tasks are thawed
 Power management notifiers are executed for PM_POST_HIBERNATION

37. Android Wakelocks
Android supports its own Power Management (on top of the standard Linux
Power Management) designed with the premise that the CPU shouldn't
consume power if no applications or services require power
Android requires that applications and services request CPU resources with
"wake locks" through the Android application framework and native Linux
libraries. If there are no active wake locks, Android will shut down the
CPU
The default behavior for the system is to suspend, even if a process is
running; keeping a system awake may involve a chain of wakelocks obtained
by various software components. Therefore Wakelocks don't go well with
the existing /sys/power/state interface
If a wakelock is being held, and if we trigger hibernation through
/sys/power/state, it will fail

38. Appendix: Code Flow in Linux 2.6.29
kernel/power/disk.c: hibernate()
 kernel/power/console.c::pm_prepare_console()
kernel/power/main.c::pm_notifier_call_chain(): Call the notifier functions registered for the event
PM_HIBERNATION_PREPARE
 fs/sync.c::sys_sync(): Sync all the file systems. Flush file system buffers, force changed blocks to disk, update the
super block
 kernel/power/disk.c::prepare_processes():
– kernel/power/process.c::freeze_processes(): Freeze the tasks
 kernel/power/disk.c::hibernation_snapshot(): Quiesce devices and create the hibernation snapshot image
– kernel/power/disk.c::platform_begin()
– kernel/power/swsusp.c::swsusp_shrink_memory():
• mm/vmscan.c::shrink_all_memory(): Free pages from memory (LRU)
– kernel/printk.c::suspend_console(): Suspend the console subsystem, this disables printk
– drivers/base/power/main.c::device_suspend(event: P_EVENT_FREEZE): For each dev in dpm_list invoke the
sequence: (dev->bus->pm, dev->type->pm, dev->class->pm)->prepare(), dev->class->pm->freeze() or
dev->class->suspend(), dev->type->pm->freeze() or dev->type->suspend(), dev->bus->pm->freeze() or
dev->bus->suspend()
– kernel/power/disk.c::platform_pre_snapshot()
– kernel/cpu.c::disable_nonboot_cpus(): Take down all the non-boot CPUs
– kernel/power/disk.c::create_image():
• arch/arm/include/asm/suspend.h::arch_prepare_suspend()

39. Appendix: Code Flow in Linux 2.6.29
• drivers/base/power/main.c::device_pm_lock(): Lock the list of active devices used by the PM core
• include/linux/irqflags.h::local_irq_disable()
• drivers/base/power/main.c::device_power_down(event: P_EVENT_FREEZE): For each dev in dpm_list
invoke: dev->bus->pm->freeze_noirq() or dev->bus->suspend_late()
• drivers/base/sys.c::sysdev_suspend(event: P_EVENT_FREEZE): For each cls in system_kset->list invoke
the sequence: (For each drv in cls->drivers)->suspend(), cls->suspend()
• arch/arm/power/cpu.c::save_processor_state(): KESSLER: Save the co-processor registers
• arch/arm/power/swsusp.S::swsusp_arch_suspend(): KESSLER:
– Save processor registers for different modes
– kernel/power/snapshot.c::swsusp_save(): Create and copy hibernation image
» Spill the per-cpu pages from the cpu back to buddy allocator
» kernel/power/snapshot.c::count_data_pages(): Compute the total number of savable non-
highmem pages
» kernel/power/snapshot.c::count_highmem_pages(): Compute the total number of savable
highmempages
» kernel/power/snapshot.c::enough_free_mem(): Make sure enough free memory for
snapshot image is available
» kernel/power/snapshot.c::swsusp_alloc(): Allocate memory for suspend image
» mm/page-alloc.c:drain_local_pages(): Kill the new cold pages created during allocation
» kernel/power/snapshot.c::copy_data_pages()
THE RESTORE CONTROL FLOW RETURNS HERE WHEN THIS HIBERNATION
IMAGE IS RESTORED
• arch/arm/power/cpu.c::restore_processor_state(): KESSLER: Restore the co-processor registers
• drivers/base/sys.c::sysdev_resume(): For each cls in system_kset->list invoke the sequence: cls-
>resume(), (For each drv in cls->drivers) ->resume()

40. Appendix: Code Flow in Linux 2.6.29
• drivers/base/power/main.c::device_power_up(event: P_EVENT_THAW): For each dev in dpm_list invoke:
dev->bus->pm->thaw_noirq() or dev->bus->resume_early()
• Include/linux/irqflags.h::local_irq_enable()
• drivers/base/power/main.c::device_pm_unlock(): Unlock the list of active PM devices used by the PM
core
– kernel/cpu.c:enable_nonboot_cpus(): Enable the non-boot CPUs
– kernel/power/disk.c::platform_finish()
– drivers/base/power/main.c::device_resume(event: P_EVENT_THAW)
– kernel/printk.c::resume_console(): Resume the console subsystem. This enables printk
– kernel/power/disk.c::platform_end()
 kernel/power/swap.c::swsusp_write(): Write entire image and metadata
– kernel/power/swap.c::swsusp_swap_check(): Check if the resume device is a swap device and get its index
– kernel/power/snapshot.c::snapshot_read_next(): Read the system memory snapshot
– kernel/power/swap.c::enough_swap(): To make sure enough swap is available to save the image
– kernel/power/swap.c::save_image(): Save the suspend image data
– kernel/power/swap.c::swsusp_close(): Close the swap device
 kernel/power/snapshot.c::swsusp_free(): Free pages allocated for suspend
kernel/power/process.c:thaw_processes(): Thaw the tasks


41. Appendix: Code Flow in Linux 2.6.29
 kernel/power/disk.c::power_down(): Shut the machine down for hibernation
– [HIBERNATION_SHUTDOWN mode]: kernel/sys.c::kernel_poweroff(): Shutdown everything and perform a
clean system power off
• kernel/sys.c::kernel_shutdown_prepare():
– Call notifiers for SYS_POWER_OFF
– drivers/base/core.c::device_shutdown(): For each dev in devices_kset->list invoke : (dev->bus or
dev->driver)->shutdown()
• kernel/cpu.c::disable_nonboot_cpus()
• drivers/base/sys.c::sysdev_shutdown: For each cls in system_kset->list invoke the sequence: cls-
>shutdown(), (For each drv in cls->drivers) ->shutdown()
• arch/arm/kernel/process.c::machine_power_off()

42. Appendix: Code Flow in Linux 2.6.29
kernel/power/disk.c: software_resume()
 drivers/base/dd.c::wait_for_device-probe(): Wait for known devices to complete their probing
 init/do_mounts.c::name_to_dev_t(): Get the major and minor numbers for the swap partition
 kernel/power/swap.c::swsusp_check(): Check for swap signature in resume device
 kernel/power/console.c::pm_prepare_console()
 kernel/power/main.c::pm_notifier_call_chain(): Call the notifier functions registered for the event
PM_RESTORE_PREPARE
 kernel/power/disk.c::prepare_processes():
– kernel/power/process.c::freeze_processes(): Freeze the tasks
 kernel/power/swap.c::swsusp_read(): Read the hibernation image
– kernel/power/swap.c::load_image(): Load the image
 kernel/power/disk.c::hibernation_restore(): Quiesce devices and restore hibernation snapshot image
– kernel/power/console.c::pm_prepare_console()
– kernel/printk.c::suspend_console(): Suspend the console subsystem, this disables printk
– drivers/base/power/main.c::device_suspend(event: P_EVENT_QUIESCE): For each dev in dpm_list invoke the
sequence: (dev->bus->pm, dev->type->pm, dev->class->pm)->prepare(), dev->class->pm->freeze() or
dev->class->suspend(), dev->type->pm->freeze() or dev->type->suspend(), dev->bus->pm->freeze() or
dev->bus->suspend()
– kernel/power/disk.c::platform_pre_restore()
– kernel/cpu.c::disable_nonboot_cpus(): Take down all the non-boot CPUs

43. Appendix: Code Flow in Linux 2.6.29
– kernel/power/disk.c::resume_target_kernel(): prepare devices that need to be suspended with interrupts off,
restore the contents of highmem that have not been restored yet from the image and run the low level code
that will restore the remaining contents of memory and switch to the just restored target kernel
• drivers/base/power/main.c::device_pm_lock(): Lock the list of active devices used by the PM core
• include/linux/irqflags.h::local_irq_disable()
• drivers/base/power/main.c::device_power_down(event: P_EVENT_QUIESCE): For each dev in dpm_list
invoke: dev->bus->pm->freeze_noirq() or dev->bus->suspend_late()
• drivers/base/sys.c::sysdev_suspend(event: P_EVENT_QUIESCE): For each cls in system_kset->list
invoke the sequence: (For each drv in cls->drivers)->suspend(), cls->suspend()
• arch/arm/power/cpu.c::save_processor_state(): KESSLER: Save the co-processor registers
• kernel/power/snapshot.c::restore_highmem(): for each highmem page that was allocated before the
suspend and included in the suspend image, and also has been allocated by the "resume" kernel swap
its current (ie. "before resume") contents with the previous (ie. "before suspend") one
• arch/arm/power/swsusp.S::swsusp_arch_resume(): KESSLER: Restore "nr_copy_pages" pages which are
saved and specified at "pagedir_nosave". Restore the processor registers in different modes.
THIS FUNCTION TRANSFERS THE CONTROL TO THE TARGET KERNEL. THE
TARGET KERNEL RESUMES FROM THE RETURN OF
arch/arm/power/swsusp.S::swsusp_arch_suspend() IN
kernel/power/disk.c::create_image()
– kernel/power/disk.c::create_image():
• arch/arm/power/swsusp.S::swsusp_arch_suspend(): returns
• arch/arm/power/cpu.c::restore_processor_state(): KESSLER: Restore the co-processor registers
• kernel/power/disk.c::platform_leave()

44. Appendix: Code Flow in Linux 2.6.29
• drivers/base/sys.c::sysdev_resume(): For each cls in system_kset->list invoke the sequence: cls-
>resume(), (For each drv in cls->drivers) ->resume()
• drivers/base/power/main.c::device_power_up(event: P_EVENT_RESTORE): For each dev in dpm_list
invoke: dev->bus->pm->thaw_noirq() or dev->bus->resume_early()
• Include/linux/irqflags.h::local_irq_enable()
• drivers/base/power/main.c::device_pm_unlock(): Unlock the list of active PM devices used by PM core
RETURN TO kernel/power/disk.c::hibernation_snapshot()
 kernel/power/disk.c::hibernation_snapshot():
– kernel/cpu.c:enable_nonboot_cpus(): Enable the non-boot CPUs
– kernel/power/dosk.c::platform_finish()
– drivers/base/power/main.c::device_resume(event: P_EVENT_RESTORE)
– kernel/printk.c::resume_console(): Resume the console subsystem. This enables printk
– kernel/power/disk.c::platform_end()
RETURN TO kernel/power/disk.c::hibernate()
kernel/power/disk.c: hibernate()
 kernel/power/snapshot.c::swsusp_free(): Free pages allocated for suspend
 kernel/power/process.c:thaw_processes(): Thaw the tasks
 kernel/power/main.c::pm_notifier_call_chain(): Call the notifier functions registered for the event
PM_POST_HIBERNATION
kernel/power/console.c::pm_restore_console()


45. References
 ACPI Specification 4.0a
 Linux kernel 2.6.29 Documentation/power
 Linux kernel 2.6.29 Code
 http://lwn.net/Articles/243404/
 http://lwn.net/Articles/318611/
 http://pdk.android.com/online-pdk/guide/power_management.html

46. END...