Analysis and comparison of three dormancy mechanisms of earlysuspend, Autosleep and Wakeup_count

First, opportunistic sleep introduction

1. Background

(1) Android-facing problems

Opportunistic sleep: When there is no task, you need to find the opportunity to enter the suspended

(2) 3 types of synchronization issues

A. Kernel: Driver during event processing, the system cannot suspend

B. User: The system cannot be suspend during user process processing

C. The kernel interacts with the user:

During the sleep process, the event is triggered and the abort suspend process is required;

Event events need to be processed by the user to suspend;

2. Earlysuspend

3. Autosleep

4. Wakeup_count

5. Comparison of three types of sleep mechanisms

(1) Discussion on Earlysuspend

A. Changed the suspend process and introduced the Earlysuspend interface;

B. The community has misunderstood the patch and considers it to be a substitute for runtime;

C. Wakelock is too complex to achieve, and the name is prone to misunderstanding;

D. mini-summit: There are Nokia developers, lack of Android developers, introduced non-technical discussion;

E. Pm_runtime should be used, cpuidle; Susupend should not exist;

F. The process of wake-up source, which runs through the whole system, has great influence;

(2) Discussion on Autosleep

A. Android Market share is getting bigger, many driver src code out of mainline;

B. Linus considers the need to merge Android features: suspend block;

C. Rafael J. Wysocki that the time was ripe for a new solution;

D. The community has misunderstood the Opportunisic suspend patch, introducing a non-technical discussion: After redesign, the name is Autosleep;

E. Wakelock is retained on the interface, considering the compatibility of Android; Implementation, the improvement was made;

(3) Discussion on Wakeup_count

A. Opportunistic sleep mechanism based on wakeup_count implementation in userspace; (similar to autosleep);

B. Kernel space, no wake_lock concept;

C. no suspend block concept;

D. Suspend trigger time, all to user space responsible;

6. Introduction of Autosleep | Reasons to Wakeup Count

(1) Earlysuspend is discarded by the kernel and needs to be patched by itself;

(2) using Earlysuspend, the kernel changes greatly, changed the suspend process, unable to merge into mainline;

(3) The impact on the device drive, the need for additional implementation of Earlysuspend interface, not conducive to upstream;

(4) Earlysuspend existing problems: such as only support switch screen when the execution of earlysuspend, not conducive to dynamic power optimization;

(5) Pm_runtime has been used in display, USB and other devices;

(6) the demand of upstream;

Second, opportunistic sleep frame

Third, wakeup source framework

1. function

A. Abstract wakeup the concept of source and wakeup event;

B. Provide the registration, enabling and other interfaces of wakeup source to each device driver;

C. Provide the device driver with wakeup event escalation, stop and other interfaces;

D. Provide wakeup event queries to the upper PM core (including wakeup count, auto Sleep, suspend, hibernate, and other modules)

Mouth, to determine whether it is possible to suspend, or whether it is necessary to terminate the ongoing suspend;

2. Data structure

(1) Registered wakeup events (CNT) and saved_count;

(2) Wakeup events in Progress (INPR);

3. Related interfaces

Iv. Wakeup Count Framework

1. Target

When there is a wake-up event to be processed:
If the system in the process of operation, can not enter the suspend;
If you have entered the suspend process, you need to exit promptly;

2. Interface

A. bool Pm_get_wakeup_count (unsigned int *count, bool block);

B. bool Pm_save_wakeup_count (unsigned int count);

3. Process

Analysis and comparison of three dormancy mechanisms of earlysuspend, Autosleep and Wakeup_count