Hibernation In Linux 2.6.29                       Author:                       Varun Mahajan                       <varun...
Contents & References    Scope of the Document    Section 1       –   ACPI Specification       –   States defined by ACP...
Scope of the Document This Document is divided into following 4 sections: ●  Section 1 covers, in brief, the concepts     ...
ACPI Specification The Advanced Configuration and Power Interface (ACPI) specification was developed to establish industry...
States defined by ACPI Specification Global Power States: Global power states apply to the entire system and are visible t...
States defined by ACPI Specification Sleeping State Definitions: Sleeping states are types of sleeping states within the g...
States defined by ACPI Specification Device Power States: Device power states are states of particular devices; as such th...
System Power Management States Standby/Power-On Suspend: This state offers minimal, though real, power savings, while prov...
System Power Management States Suspend-to-RAM This state offers significant power savings as everything in the system is p...
System Power Management States Suspend-to-Disk (Hibernation) This state offers the greatest power savings. This state oper...
System Power Management States             
Sysfs Interface The interface exists in /sys/power/ directory /sys/power/state: This controls the system power state Readi...
Sysfs Interface /sys/power/disk: This controls the operating mode of the Suspend-to-Disk mechanism Operating modes:  plat...
Sysfs Interface /sys/power/image_size: This controls the size of the image created by the Suspend-to-Disk mechanism It can...
Tasks: Freeze, Thaw The freezing of tasks is a mechanism by which user space processes and some kernel threads are control...
Tasks: Freeze, Thaw kernel/power/process.c, include/linux/freeze.h Freeze: freeze_processes(): It executes try_to_freeze_t...
Tasks: Freeze, Thaw Thaw: thaw_processes(): It clears the PF_FROZEN flag for each frozen task. Then the tasks that have be...
Tasks: Freeze, Thaw Why is freezing of tasks required:   To prevent filesystems from being damaged after hibernation. The...
Device Power Management System Sleep Model: Drivers can enter low power states as part of entering system-wide low-power s...
Device Power Management include/linux/device.h: Bus Driver Methods: The core methods to suspend and resume devices reside ...
Device Power Management Upper layers of driver stacks: Device drivers generally have at least two interfaces, and the but_...
Device Power Management Device: struct device {  ...  struct device_type *type;  struct bus_type *bus;  struct class *clas...
Device Power Management include/linux/sysdev.h: Sysdev: struct sysdev_class { …  struct list_head drivers;  int (*shutdown...
Device Power Management include/linux/pm.h: struct dev_pm_ops {  int (*prepare)(struct device *dev);  void (*complete)(str...
Device Power Management  prepare(): Prepare the device for the upcoming transition, but do NOT change its hardware state....
Device Power Management  poweroff(): Hibernation-specific, executed after saving a hibernation image. Quiesce the device,...
Device Power Management Relevant P_EVENT_ messages:  P_EVENT_FREEZE: System is going to hibernate, call prepare() and fre...
Notifiers  There are some operations that device drivers may want to carry out in their  suspend()/prepare() routines, but...
Notifiers   PM_RESTORE_PREPARE: The system is going to restore a hibernation image.  If all goes well the restored kernel...
Memory Snapshot The hibernation core snapshots system memory by indexing and copying every active page in the system. Once...
Hibernate        Execute  HIBERNATION_PREPARE                                                                    Shutdown ...
Hibernate  The power management notifiers registered for the event PM_HIBERNATION_PREPARE are executed All the filesyste...
Hibernate    Co-processor and the processor state is saved    Atomic copy of the system memory (hibernation image) is cr...
Resume  Probe of known Devices              Proceed with the Current                                          Execute     ...
Resume    Probing of the known devices is allowed to be finished before proceeding    The swsusp signature is checked fo...
Resume    Control is passed to the target kernel. This also restores the processor state    Co-processor state is restor...
Android Wakelocks Android supports its own Power Management (on top of the standard Linux Power Management) designed with ...
Appendix: Code Flow in Linux 2.6.29 kernel/power/disk.c: hibernate()    kernel/power/console.c::pm_prepare_console() ker...
Appendix: Code Flow in Linux 2.6.29     •   drivers/base/power/main.c::device_pm_lock(): Lock the list of active devices u...
Appendix: Code Flow in Linux 2.6.29               •   drivers/base/power/main.c::device_power_up(event: P_EVENT_THAW): For...
Appendix: Code Flow in Linux 2.6.29    kernel/power/disk.c::power_down(): Shut the machine down for hibernation         –...
Appendix: Code Flow in Linux 2.6.29 kernel/power/disk.c: software_resume()    drivers/base/dd.c::wait_for_device-probe():...
Appendix: Code Flow in Linux 2.6.29     –   kernel/power/disk.c::resume_target_kernel(): prepare devices that need to be s...
Appendix: Code Flow in Linux 2.6.29               •   drivers/base/sys.c::sysdev_resume(): For each cls in system_kset->li...
References    ACPI Specification 4.0a    Linux kernel 2.6.29 Documentation/power    Linux kernel 2.6.29 Code    http:/...
END...     
Upcoming SlideShare
Loading in …5
×

Hibernation in Linux 2.6.29

9,049 views

Published on

Published in: Education, Technology
1 Comment
19 Likes
Statistics
Notes
  • There is a 2 step procedure to do the same. Very easy and effective.
    Follow it here, cheers.
    http://3ur.in/7ca40
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
9,049
On SlideShare
0
From Embeds
0
Number of Embeds
67
Actions
Shares
0
Downloads
0
Comments
1
Likes
19
Embeds 0
No embeds

No notes for slide

Hibernation in Linux 2.6.29

  1. 1. Hibernation In Linux 2.6.29 Author: Varun Mahajan    <varunmahajan06@gmail.com>
  2. 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. 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. 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. 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 systems 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. 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. 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. 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 dont, are left on    
  9. 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. 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. 11. System Power Management States    
  12. 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. 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. 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. 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. 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 tasks 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. 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. 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 dont 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. 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. 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. 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. 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. 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. 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. 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 drivers 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. 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 drivers 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. 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. 28. Notifiers There are some operations that device drivers may want to carry out in their suspend()/prepare() routines, but shouldnt, 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 shouldnt be done after the swsusps 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Android Wakelocks Android supports its own Power Management (on top of the standard Linux Power Management) designed with the premise that the CPU shouldnt 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 dont 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. END...   

×