首页 > 移动开发 > earlysuspend调用过程

earlysuspend调用过程

1. 电源管理的状态

Android的Linux内核为系统提供了4种电源状态,内核的源代码为其中的3种定义了名字和对应的宏定义,名字定义在kernel/power/suspend.c中:

 

1

2

3

4

5

6

7

constchar*const pm_states[PM_SUSPEND_MAX]={

#ifdef CONFIG_EARLYSUSPEND

      [PM_SUSPEND_ON]        ="on",

#endif

      [PM_SUSPEND_STANDBY]   ="standby",

      [PM_SUSPEND_MEM] ="mem",

};

 

对应的宏定义在:include/linux/suspend.h中:

 

1

2

3

4

5

6

typedefint __bitwise suspend_state_t;

#define PM_SUSPEND_ON          ((__force suspend_state_t) 0)

#define PM_SUSPEND_STANDBY     ((__force suspend_state_t) 1)

#define PM_SUSPEND_MEM         ((__force suspend_state_t) 3)

#define PM_SUSPEND_MAX         ((__force suspend_state_t) 4)

 

很奇怪的是,第四种状态(disk)没有具体的定义,而是硬编码在代码中,不明白为什么会这样做,至少我现在看的版本是这样(2.6.35),这种就是所谓的suspend to disk或者叫hibernate。不过这不是重点,再说,目前也很少有Android的设备支持hibernate。

顾名思义:

PM_SUSPEND_ON— 设备处于全电源状态,也就是正常工作状态;

PM_SUSPEND_STANDBY— 设备处于省电状态,但还可以接收某些事件,具体的行为取决与具体的设备;

PM_SUSPEND_MEM— suspend to memory,设备进入睡眠状态,但所有的数据还保存在内存中,只有某些外部中断才可以唤醒设备;

目前,大多数的Android设备都只支持其中的两种:PM_SUSPEND_ON 和 PM_SUSPEND_MEM,所以下面的讨论说道suspend的地方,均是指PM_SUSPEND_MEM。

2. Early Suspend、Late Resume

Early Suspend和Late Resume是Android在标准Linux的基础上增加的一项特性。当用户空间的向内核请求进入suspend时,这时候会先进入early suspend状态,驱动程序可以注册early suspend的回调函数,当进入该状态时,内核会逐一地调用这些回调函数。例如显示屏的驱动程序通常会注册early suspend,在他的回调函数中,驱动程序会把屏幕和背光都关闭。在这种状态下,所有的后台进程都还在活动中,该播放歌曲的播放歌曲,该下载数据的依然在下载,只是显示屏不良而已。进入early suspend状态以后,一旦所有的电源锁(wake lock)被释放,系统马上会进入真正的suspend流程,直到最后系统停止工作,等待外部事件的唤醒。

3. Android的电源锁机制:wake lock

Android相比标准的Linux内核,在电源管理中加入了wake lock机制。一旦申请了某种类型的锁,电源管理模块将会“锁住”某一种电源状态,目前,Android提供了两种类型的锁:

WAKE_LOCK_SUSPEND— 阻止系统进入suspend状态;

WAKE_LOCK_IDLE— 阻止系统进入idle状态;

wake lock也可以设定超时,时间一到,自动释放该锁。

有关wake lock的代码在:kernel/power/wakelock.c中。

4. 电源状态迁移

内核启动完成以后,电源管理系统会在sysfs文件系统中建立3个文件:

 

1

2

3

    /sys/power/state

    /sys/power/wake_lock

    /sys/power/wake_unlock

 

电源状态的迁移首先由用户空间的应用程序发起,当系统应用检测到一定时间内没有用户活动后(例如触摸屏、按键),可以向/sys/power/state文件写入相应的电源状态名称(请参考第一节内容),如果写入“mem”,将会触发内核启动suspend的流程,内核将会按照图2.1进行状态的迁移。应用程序也可以通过/sys/power/wake_lock申请一个WAKE_LOCK_SUSPEND 类型的锁,相应地,通过/sys/power/wake_unlock则可以释放一个锁。内核在进入suspend之前如果检测到某个锁没有释放,则会放弃本次的suspend过程,直到这个锁释放为止。

 

 

基于Android的Linux内核的电源管理:Early Suspend

1. 用户空间的接口
在kernel/power/main.c中,定义了一组sysfs的属性文件,其中一个定义是:
power_attr(state);
把这个宏展开后:

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

staticstruct kobj_attribute state_attr={ \

        .attr={                               \

                 .name="state",   \

                 .mode=0644,                          \

        },                                           \

        .show     =state_show,                          \

        .store      =state_store,                 \

}

 

我们再看看main.c的入口:

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

staticint __init pm_init(void)

{

    ......

        power_kobj=kobject_create_and_add("power", NULL);

        if(!power_kobj)

                 return-ENOMEM;

        return sysfs_create_group(power_kobj,&attr_group);

}

 

显然,该函数执行后,会在生成/sys/power目录,该目录下会建立一系列属性文件,其中一个就是/sys/power/state文件。用户空间向该文件的写入将会导致state_store被调用,读取该文件将会导致state_show函数被调用。

现在回到Android的HAL层中,查看一下代码:hardware/libhardware_legacy/power/power.c:

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

 //定义写入/sys/power/state的命令字符串

staticconst char*off_state="mem";

staticconst char*on_state="on";

//打开/sys/power/state等属性文件,保存相应的文件描述符

staticint

open_file_descriptors(constchar*const paths[])

{

    int i;

    for(i=0; i

最终,用户空间的电源管理系统会调用set_screen_state函数来触发suspend的流程,该函数实际上就是往/sys/power/state文件写入"mem"或"on"命令字符串。

<pre lang="c" line="1">int

set_screen_state(inton)

{

    ......

    initialize_fds();

    ......

    char buf[32];

    int len;

    if(on)

        len = snprintf(buf,sizeof(buf),"%s", on_state);

    else

        len = snprintf(buf,sizeof(buf),"%s", off_state);

    buf[sizeof(buf)-1]='\0';

    len = write(g_fds[REQUEST_STATE], buf,len);

    ......

    return0;

}

 

2. 内核中数据结构和接口

与earlysuspend相关的数据结构和接口都在earlysuspend.h中进行了定义。

- early_suspend结构

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

struct early_suspend{

#ifdef CONFIG_HAS_EARLYSUSPEND

         structlist_head link;

         int level;

         void(*suspend)(struct early_suspend *h);

         void(*resume)(struct early_suspend *h);

#endif

};

 

希望执行early suspend的设备,他的设备驱动程序需要向电源管理系统注册,该结构体用于向电源管理系统注册earlysuspend/lateresume,当电源管理系统启动suspend流程时,回调函数suspend会被调用,相反,resume的最后阶段,回调函数resume会被调用,level字段用于调整该结构体在注册链表中的位置,suspend时,level的数值越小,回调函数的被调用的时间越早,resume时则反过来。Android预先定义了3个level等级:

 

1

2

3

4

5

enum{

      EARLY_SUSPEND_LEVEL_BLANK_SCREEN=50,

      EARLY_SUSPEND_LEVEL_STOP_DRAWING=100,

      EARLY_SUSPEND_LEVEL_DISABLE_FB=150,

};

 

如果你想你的设备在FB设备被禁止之前执行他的early suspend回调,设备驱动程序应该把level值设定为小于150的某个数值,然后向系统注册early_suspend结构。注册和反注册函数是:

 

1

2

     void register_early_suspend(struct early_suspend *handler);

     void unregister_early_suspend(struct early_suspend *handler);

 

early_suspend_handlers链表

所有注册到系统中的early_suspend结构都会按level值按顺序加入到全局链表early_suspend_handlers中。

3. 工作流程

首先,我们从kernel/power/wakelock.c中的初始化函数开始:

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

staticint __init wakelocks_init(void)

{

      int ret;

      int i;

    ......

      for(i=0; i&lt; ARRAY_SIZE(active_wake_locks); i++)

            INIT_LIST_HEAD(&amp;active_wake_locks[i]);

    ......

      wake_lock_init(&amp;main_wake_lock, WAKE_LOCK_SUSPEND,"main");

      wake_lock(&amp;main_wake_lock);

      wake_lock_init(&amp;unknown_wakeup, WAKE_LOCK_SUSPEND,"unknown_wakeups");

    ......

      ret= platform_device_register(&amp;power_device);

      ret = platform_driver_register(&amp;power_driver);

    ......

      suspend_work_queue= create_singlethread_workqueue("suspend");

    ......

      return0;

}

 

可以看到,显示初始化active_wake_locks链表数组,然后初始化并且锁住main_wake_lock,注册平台设备power_device,这些数组、锁和power_device我们在后续文章再讨论,这里我们关注的最后一个动作:创建了一个工作队列线程suspend_work_queue,该工作队列是earlysuspend的核心所在。

系统启动完成后,相关的驱动程序通过register_early_suspend()函数注册了early suspend特性,等待一段时间后,如果没有用户活动(例如按键、触控等操作),用户空间的电源管理服务最终会调用第一节提到的set_screen_state()函数,透过sysfs,进而会调用到内核中的state_store():

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

static ssize_t state_store(struct kobject*kobj,struct kobj_attribute*attr,

                     constchar*buf, size_t n)

{

#ifdef CONFIG_SUSPEND

#ifdef CONFIG_EARLYSUSPEND

      suspend_state_t state = PM_SUSPEND_ON;

#else

      suspend_state_t state = PM_SUSPEND_STANDBY;

#endif

      constchar*const*s;

#endif

      char*p;

      int len;

      int error=-EINVAL;

      p = memchr(buf,'\n', n);

      len = p ? p- buf : n;

      /* First, check if we are requested to hibernate */

      if(len==4&amp;&amp;!strncmp(buf,"disk", len)){

            error = hibernate();

  goto Exit;

      }

#ifdef CONFIG_SUSPEND

      for(s=&amp;pm_states[state]; state &lt; PM_SUSPEND_MAX; s++, state++){

            if(*s&amp;&amp; len== strlen(*s)&amp;&amp;!strncmp(buf,*s, len))

                  break;

      }

      if(state&lt; PM_SUSPEND_MAX&amp;&amp;*s)

#ifdef CONFIG_EARLYSUSPEND

            if(state== PM_SUSPEND_ON|| valid_state(state)){

                  error =0;

                  request_suspend_state(state);

            }

#else

            error = enter_state(state);

#endif

#endif

 Exit:

      return error? error : n;

}

 

看到了没,前一篇文章说过,suspend to disk做了特殊处理,这里直接比较传入的字符串,而不是使用后续的pm_states数组,这里我不关心suspend to disk,所以略过hibernate的分析。

紧接着,通过pm_states数组,根据命令字符串查询得到请求的状态,默认情况下,Android的内核都会配置了CONFIG_EARLYSUSPEND,所以会调用request_suspend_state()函数,不过在调用该函数之前会先valid_state()一下,这给了平台相关的代码一个机会确认该平台是否支持所请求的电源状态。valid_state()的具体实现请参考内核代码树。

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

void request_suspend_state(suspend_state_t new_state)

{

      unsignedlong irqflags;

      int old_sleep;

      spin_lock_irqsave(&amp;state_lock, irqflags);

      old_sleep = state &amp; SUSPEND_REQUESTED;

    ......

      if(!old_sleep&amp;&amp; new_state!= PM_SUSPEND_ON){

            state |= SUSPEND_REQUESTED;

            if(queue_work(suspend_work_queue,&amp;early_suspend_work))

                  pr_info("early_suspend_work is in queue already\n");

      }elseif(old_sleep&amp;&amp; new_state== PM_SUSPEND_ON){

            state &amp;= ~SUSPEND_REQUESTED;

            wake_lock(&amp;main_wake_lock);

            if(!queue_work(suspend_work_queue,&amp;late_resume_work))

                  pr_info("late_resume_work is in queue already\n");

      }

      requested_suspend_state = new_state;

      spin_unlock_irqrestore(&amp;state_lock, irqflags);

}

 

还记得前面初始化时建立的工作队列suspend_woek_queue吗?根据之前的电源状态和请求的状态, request_suspend_state()只是简单地向suspend_work_queue中加入early_suspend_work或者是late_resume_work并调度他们执行。early_suspend_work的工作函数是early_suspend():

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

staticvoid early_suspend(struct work_struct*work)

{

        struct early_suspend*pos;

        unsignedlong irqflags;

        int abort=0;

        mutex_lock(&amp;early_suspend_lock);

        spin_lock_irqsave(&amp;state_lock,irqflags);

        if(state== SUSPEND_REQUESTED)

                 state |= SUSPENDED;

        else

                 abort =1;

        spin_unlock_irqrestore(&amp;state_lock,irqflags);

        if(abort){

        ......

        }

    ......

        list_for_each_entry(pos,&amp;early_suspend_handlers, link){

                 if(pos-&gt;suspend!= NULL){

                           if(debug_mask&amp;DEBUG_SUSPEND)

                                    printk(KERN_DEBUG"pos-&gt;suspend: %pF begin\n", pos-&gt;suspend);

                           pos-&gt;suspend(pos);

                           if(debug_mask&amp;DEBUG_SUSPEND)

                                    printk(KERN_DEBUG"pos-&gt;suspend: %pF finish\n", pos-&gt;suspend);

                 }

        }

        mutex_unlock(&amp;early_suspend_lock);

        if(debug_mask&amp; DEBUG_SUSPEND)

                 pr_info("early_suspend:sync\n");

        sys_sync();

abort:

        spin_lock_irqsave(&amp;state_lock,irqflags);

        if(state==SUSPEND_REQUESTED_AND_SUSPENDED)

                 wake_unlock(&amp;main_wake_lock);

        spin_unlock_irqrestore(&amp;state_lock,irqflags);

}

 

终于看到啦,early_suspend()遍历early_suspend_handlers链表,从中取出各个驱动程序注册的early_suspend结构,然后调用它的suspend回调函数。最后,释放main_wake_lock锁,至此整个earlysuspend的流程完成。下面的序列图清晰地表明了整个调用的过程:

但是,这时整个系统只是处于所谓的idle状态,cpu还在工作,后台进程也在工作中,那什么时候系统会真正地进入睡眠状态?注意到最后一句关键的调用了没有:
wake_unlock(&main_wake_lock);


本文固定链接: http://www.devba.com/index.php/archives/781.html | 开发吧

报歉!评论已关闭.