A. linux触摸屏驱动中什么时候会调用suspend这个函数
android系统摁下电源键后会让系统进入休眠以达到节电的目的。内核驱动中和休眠相关的就是suspend和resume函数。
suspend函数用于休眠，resume函数用于唤醒。下面分析驱动中的这两个函数是如何被调用到的。
驱动部分：
首先需要分析驱动的注册过程，较新的内核都是采用DTS方式来取代在内核中直接定义platform_device数据结构的注册方式，本文是基于DTS机制的内核来分析。
proct对应的dts文件在编译时被编译为dtb文件，uboot在启动时候会将其地址传给内核，内核在启动过程中会去解析，具体解析是在start_kernel()->setup_arch() --> unflatten_device_tree()中具体分析可以参考网上，解析的最终结果会存放在allnodes地址处，这个allnodes随后在machine的init函数
中被使用，init函数中会根据allnodes中的节点数据组合成platform_device数据结构，然后将其注册到platform总线上，下面简要分析一下并重点关注这些初始化过程中和
pm相关的初始化。
我参与的项目中machine的init函数就是via_init_machine函数，在这个函数中就是调用了of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL)这个函数来解析allnodes的。of_platform_populate是系统提供的接口。下面分析这个接口的实现：
[html] view plain
int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent)
{
struct device_node *child;
int rc = 0;
root = root ? of_node_get(root) : of_find_node_by_path("/");
if (!root)
return -EINVAL;
for_each_child_of_node(root, child) {
rc = of_platform_bus_create(child, matches, lookup, parent, true);
if (rc)
break;
}
of_node_put(root);
return rc;
}
root最后就是取到的根节点，然后其作为参数传递给of_platform_bus_create，of_platform_device_create_pdata的实现如下：
[html] view plain
static int of_platform_bus_create(struct device_node *bus,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent, bool strict)
{
const struct of_dev_auxdata *auxdata;
struct device_node *child;
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
int rc = 0;
/* Make sure it has a compatible property */
if (strict && (!of_get_property(bus, "compatible", NULL))) {
pr_debug("%s() - skipping %s, no compatible prop\n",
__func__, bus->full_name);
return 0;
}
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
platform_data = auxdata->platform_data;
}
if (of_device_is_compatible(bus, "arm,primecell")) {
of_amba_device_create(bus, bus_id, platform_data, parent);
return 0;
}
dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
if (!dev || !of_match_node(matches, bus))
return 0;
for_each_child_of_node(bus, child) {
pr_debug(" create child: %s\n", child->full_name);
rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict);
if (rc) {
of_node_put(child);
break;
}
}
return rc;
}
根据传入参数，我们这里直接分析of_platform_device_create_padate函数，如下:
[html] view plain
struct platform_device *of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
struct device *parent)
{
struct platform_device *dev;
if (!of_device_is_available(np))
return NULL;
dev = of_device_alloc(np, bus_id, parent);
if (!dev)
return NULL;
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
#endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
*/
if (of_device_add(dev) != 0) {
platform_device_put(dev);
return NULL;
}
return dev;
}
of_platform_device_create_padate->of_device_alloc->platform_device_alloc
便在platform_device_alloc函数中进行进行alloc和初始化了，实现如下：
[html] view plain
struct platform_device *platform_device_alloc(const char *name, int id)
{
struct platform_object *pa;
pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
if (pa) {
strcpy(pa->name, name);
pa->pdev.name = pa->name;
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
}
可以看到有个device_initialize，这里面对pdev.dev做一些列的初始化，其中有一个函数就是device_pm_init，这个函数就是我们一直关心的device相关的pm函数，具体实现如下：
[html] view plain
void device_pm_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
init_completion(&dev->power.completion);
complete_all(&dev->power.completion);
dev->power.wakeup = NULL;
spin_lock_init(&dev->power.lock);
pm_runtime_init(dev);
INIT_LIST_HEAD(&dev->power.entry);
dev->power.power_state = PMSG_INVALID;
}
可以看见它对device和功耗相关的数据做了一些初始化，我们这里先重点关注下dev->power.entry，初始化一个链表头，所以他/它很有可能会在后面加到某个链表里面去，而那个链表应该是用来保存所有的device用的。系统中所有的platform_device都是通过这种方式注册到系统中的，那么应该所有的platform_device都会初始化一个dev->power.entry，如果到时候把所有的dev->power.entry都添加到某个链表上去，那么系统到时候查询的时候只要找到这个list head就可以找到所有的platform_device了。嗯，不过这是我们的猜测。我们接下去分析来验证下。
platform_device通过alloc之后已经初始化好了，那么接下去就可以添加到系统中了，所以我们再回头看of_platform_device_create_pdata的实现。
函数在of_device_alloc之后把dev->dev.bus赋值给了platform_bus_type，接着就调用了of_device_add函数，在of_device_add函数中最后通过device_add添加到了bus上，但是device_add中有个函数需要我们关系，就是device_pm_add(dev)，实现如下：
[html] view plain
void device_pm_add(struct device *dev)
{
pr_debug("PM: Adding info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
mutex_lock(&dpm_list_mtx);
if (dev->parent && dev->parent->power.is_prepared)
dev_warn(dev, "parent %s should not be sleeping\n",
dev_name(dev->parent));
list_add_tail(&dev->power.entry, &dpm_list);
dev_pm_qos_constraints_init(dev);
mutex_unlock(&dpm_list_mtx);
}
可以看到这里list_add_tail(&dev->power.entry, &dpm_list);这就验证了我们之前的猜测。所有注册到系统中的设备，最终都是会添加到dpm_list这条链表上。
那么系统在休眠的时候是如何通过dmp_list这表链表来suspend设备的呢？接下去就是我们要分析的电源管理部分内容。
系统电源部分：
电源管理相关文件在kernel/power目录下，前面已经分析到。系统中注册的设备都是会添加到dmp_list这条链表上的。那么睡眠的时候系统应该是会查找dmp_list这条链表，
然后通过这条链表依次去查到对应的driver，然后调用driver中的suspend方法。下面我们来验证。
2.在suspend会轮询bus下的driver，然后一次调用到driver->pm->suspend方法，然后进入休眠。
3.state_store->pm_suspend->enter_state->suspend_devices_and_enter->dpm_suspend_start->dpm_suspend->device_suspend->__device_suspend->pm_op->(ops->suspend)
B. Linux内核睡眠唤醒状态
Linux内核支持四种系统睡眠状态即： mem、standby、freeze and disk 。
可通过文件 /sys/power/state 进行读写访问，区别如下：
在 RockPI 4A 单板 Debian 系统 Linux 4.4 内核中，查看电源状态，仅支持 freeze和mem 两种。
原因：
1、 Platform 驱动只实现了 mem 类型的 suspend
2、只有在 hibernation 可用时，才支持 STD
1、 psci 初始化流程
suspend_set_ops() 函数赋值数组 pm_states 实现如下：
2、power state显示
/sys/power/state 文件显示的内容，通过 state_show() 函数实现，该函数最终显示数组 pm_states 的内容。
参考：
Documentation/power/states.txt
C. linux中程序处于停止态可以被唤醒吗
在Linux中,休眠主要分三个主要的步骤:
1) 冻结用户态进程和内核态任务
2) 调用注册的设备的suspend的回调函数, 顺序是按照注册顺序
3) 休眠核心设备和使CPU进入休眠态, 冻结进程是内核把进程列表中所有的进程的状态都设置为停止,并且保存下所有进程的上下文.
当这些进程被解冻的时候,他们是不知道自己被冻结过的,只是简单的继续执行。
如何让Linux进入休眠呢?用户可以通过读写sys文件/sys /power/state 是实现控制系统进入休眠. 比如
# echo mem > /sys/power/state
命令系统进入休眠. 也可以使用
# cat /sys/power/state
来得到内核支持哪几种休眠方式.
1. 相关代码
• kernel/kernel/power/main.c
• kernel/arch/arm/mach-xxx/pm.c
• kernel/driver/base/power/main.c
接下来让我们详细的看一下Linux是怎么休眠/唤醒的:
用户对于/sys/power/state 的读写会调用到 kernel/kernel/power/main.c中的state_store()，
用户可以写入 const char * const pm_states[] 中定义的字符串， 比如"mem", "standby"。
const char *const pm_states[PM_SUSPEND_MAX] = {
#ifdef CONFIG_EARLYSUSPEND
[PM_SUSPEND_ON] = "on",
#endif
[PM_SUSPEND_STANDBY] = "standby",
[PM_SUSPEND_MEM] = "mem",
};
常见有standby(suspend to RAM)、mem(suspend to RAM)和disk(suspend to disk)，只是standby耗电更多，返回到正常工作状态的时间更短。
然后state_store()会调用enter_state()<注：这是经典Linux调用流程， 在Android系统中，
Kernel将调用request_suspend_state，而不是enter_state>，它首先会检查一些状态参数，然后同步文件系统。
2. 准备, 冻结进程
当进入到suspend_prepare()中以后， 它会给suspend分配一个虚拟终端来输出信息， 然后广播一个系统要进入suspend的Notify，
关闭掉用户态的helper进程， 然后一次调用suspend_freeze_processes()冻结所有的进程， 这里会保存所有进程当前的状态，
也许有一些进程会拒绝进入冻结状态， 当有这样的进程存在的时候， 会导致冻结失败,此函数就会放弃冻结进程，并且解冻刚才冻结的所有进程。
3. 让外设进入休眠
现在, 所有的进程(也包括workqueue/kthread) 都已经停止了，内核态人物有可能在停止的时候握有一些信号量，
所以如果这时候在外设里面去解锁这个信号量有可能会发生死锁，所以在外设的suspend()函数里面作lock/unlock锁要非常小心，
这里建议设计的时候就不要在suspend()里面等待锁。而且因为suspend的时候，有一些Log是无法输出的，所以一旦出现问题,非常难调试。
然后kernel在这里会尝试释放一些内存。
最后会调用suspend_devices_and_enter()来把所有的外设休眠， 在这个函数中，
如果平台注册了suspend_ops(通常是在板级定义中定义和注册，在kernel/arch/arm/mach-xx/pm.c中调用suspend_set_ops)，
这里就会调用 suspend_ops->begin()； 然后调用dpm_suspend_start，他们会依次调用驱动的suspend() 回调来休眠掉所有的设备。
当所有的设备休眠以后， suspend_ops->prepare()会被调用， 这个函数通常会作一些准备工作来让板机进入休眠。
接下来Linux，在多核的CPU中的非启动CPU会被关掉，通过注释看到是避免这些其他的CPU造成race condio，接下来的以后只有一个CPU在运行了。
suspend_ops 是板级的电源管理操作, 通常注册在文件 arch/arch/mach-xxx/pm.c 中.
接下来， suspend_enter()会被调用， 这个函数会关闭arch irq， 调用 device_power_down()， 它会调用suspend_late()函数，
这个函数是系统真正进入休眠最后调用的函数，通常会在这个函数中作最后的检查。 如果检查没问题， 接下来休眠所有的系统设备和总线，
并且调用 suspend_pos->enter() 来使CPU进入省电状态，这时就已经休眠了。代码的执行也就停在这里了。
三、Linux Resume流程
如果在休眠中系统被中断或者其他事件唤醒，接下来的代码就会开始执行，这个唤醒的顺序是和休眠的循序相反的，
所以系统设备和总线会首先唤醒，使能系统中断，使能休眠时候停止掉的非启动CPU， 以及调用suspend_ops->finish()，
而且在suspend_devices_and_enter()函数中也会继续唤醒每个设备，使能虚拟终端， 最后调用 suspend_ops->end()。
在返回到enter_state()函数中的，当 suspend_devices_and_enter() 返回以后，外设已经唤醒了，
但是进程和任务都还是冻结状态， 这里会调用suspend_finish()来解冻这些进程和任务， 而且发出Notify来表示系统已经从suspend状态退出， 唤醒终端。
到这里，所有的休眠和唤醒就已经完毕了，系统继续运行了。
D. 真心请问Linux kernel进入Suspend有关问题
就是如此简单 2.6内核的编译安装已经大大简化了 当然 新的内核被拷贝到 /boot后 还是需要手动修改 gurb.conf / menu.lst的
E. 如何在Android 或Linux 下，做Suspend /Resume 的Debug
在Linux或Android下，做power management 的调适时，常遇到没有足够的information，可以做为debug时的依据和参考
我们整理了几个常用的参数或Command，可供设计者，得到足够的Informaiton 做Suspend / Resume的function Debug。
加boot 参数 no_console_suspend
基本上我们常常使用console做为suspend function的debug的Information source，但原始的source code在suspend过程中，会将console关掉。所以我们看到一定程度後就再也看不到message了。
但是我们并不知道在Suspend的过程中，系统到底发生了什麼事，可能造成无法suspend。
为此，我们就会在kernel 启动参数中加上no_console_suspend这个参数。在AM/DM37x APM中是修改boot.scr档案参数
#!/bin/sh
cat <<EOF > boot.cmd
if fatload mmc 0 82000000 uImage
then
echo ***** Kernel: /dev/mmcblk0p1/uImage *****
fi
echo ***** RootFS: /dev/mmcblk0p2 *****
# Pantherboard DVI output
#setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi vram=32M omapfb.mode=dvi:1280x720MR-32 omapfb.vram=0:16M mpurate=1000'
# Pantherboard LCD output
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000'
将no_console_suspend加上去到boot 参数後就好了
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 no_console_suspend'
如果是OMAP4 APM的话，请修改Kernel 参数的所在档案即可(在U-boot Source code中)
这个是基本的参数，所以在Android或Linux上都可以使用。 kernel把console suspend掉以後， 不管里面出了什麼事情， 在Console上都看不到。 而使用这个参数後，大部分在suspend/resume时候的死机都可以通过Console看到kernel Panic的信息， 这样我们才会知道是哪里出了问题。 因为有的时候resume出错， 或者suspend到很後面出错的console不加这个参数都看不到。
但这个参数在TI OMAP3/OMAP4/AM37x/DM37x有可能造成有时Suspend 完当掉或是resume 失败的问题，假如已经抓到问题在那的时候，您就可以将这个参数Disable，不然很可能就会Debug不下去。
initcall_debug
这个同样kernel参数，使用的时机是，当我们不知道是那个driver在suspend/resume过程中出错的时候，可以使用这个参数来找出问题所在。在下完这个参数後，Kernel在suspend时，会将每个driver或task的状况report出来。我们可以藉由这些information，Check 在suspend时，每个task和driver是否已经完成进suspend 的相关准备工作…
打开这个参数的方法有二种
一种是在console下Command，启动这个function…
echo 1 > /sys/mole/kernel/parameters/initcall_debug
echo 9 > /proc/sys/kernel/printk
其中上面的第一条命令是打开initcall_debug， 这个是所有的kernel都会有的。
而第二条命令是要提高kernel message 级别，因为initcall的这些信息都是KERN_DEBUG级别的， 所以需要提高printk的级别才可以看到， 要不然suspend/resume的时候挂了，你就没有机会看到这些信息了。
另一种启动方法是写在kernel的启动参数下，就可以了。
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 initcall_debug no_console_suspend'
同样的，这个参数也有可能造成AM37x/DM37x/OMAP4 APM发生进suspend当掉的问题。所以一旦知道问题所在，麻烦请将这个参数Disable掉。
suspend_test
这个方法可以用rtc这种软件的方式来做循环的suspend/resume， 尽管对於Android这样并不是很足够， （还要再模拟一个POWER_KEY上去才够）， 但是对於测试Driver的稳定性， 还是有一定用处的。不要认为suspend了几次可以，那麼就可以通过几千次的测试。这个suspend是5秒钟用RTC唤醒，然後回到Android後5秒钟又会自动睡下去，但是对於通用Linux，你可以写个script来让他起来一会再睡下去，或许这个工具比较有用rtcwakeup（google rtcwakeup)。
使用方法：
编译一个有这个功能的kernel， make menuconfig 以後选上
CONFIG_PM_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
这两个选项，烧写新的kernel，然後打开你需要测试的Device， 比如WIFI，3G
echo "core" > /sys/power/pm_test
echo "mem" > /sys/power/state
这样， 它就会循环休眠和唤醒了。
wakelock
Android和Linux在Power Management相关的最大的就是wakelock机制的有无。Android有时候会碰到suspend进不去，或者suspend到最後又莫名奇妙的wake up的问题。这些都有可能是wakelock引起的，或者说是wakelock的使用者引起的。怎麼fine tune呢，使用Console在Android 系统下设定：
echo 15 > /sys/mole/wakelock/parameters/debug_mask
echo 15 > /sys/mole/userwakelock/parameters/debug_mask
15是代表16进制的F， 在wakelock里面就是把所有的debug信息打开， 起码现在是这样设定的。如果以後不够用了，可能就会改成255.
这样你能看到kernel和frameworks层对於wakelock的操作、申请及释放。这样看申请和释放成对否就可以了。
注意： wakelock有一种是timeout的，就是说多少毫秒以後，会自动释放，对於这些wakelock，申请和释放可能是不成对的。
power.0
有时看到系统suspend到了最後， 然後遇到power.0後suspend失败，然後整个系统又resume回来。这个是android专有的，因为power.0是android注册到suspend最後的一个行程， 它会在CPU进入suspend之前检查一下有没有wakelock存在， 如果这时候还有没有释放的wakelock， 那麼它会return -EBUSY然後导致整个suspend失败。 Check这个问题的方法就是把上面wakelock的debug信息打开，然後看看是哪个去申请了wakelock，然後Release它。
这个错误的错误信息大概是这样的：
pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11
PM: Device power.0 failed to suspend late: error -11
earlysuspend
在android里面中另外一个和Power Management有相关的机制叫earlysuspend， 同样可以打开debug message，用来做Android earlysuspend debug之用：
echo 15 > /sys/mole/earlysuspend/parameters/debug_mask
来把相关的debug信息印出来， 例如那个earlysuspend要被call之类的。
suspend/resume 时间 fine tune
有的时候你要调试suspend/resume的时间太慢的问题。 一种方法是用initcall_debug， 然後把printk的时间戳打上， 然後看那个process最慢，再来Check原因是什麼
我有一个patch，专门用来调试这个问题的，但是upstream不接受， 说非要用这种折磨人的方法才行， 但是如果你想用可以下下来打上去用一下。
地址在这里:http://www.spinics.net/lists/linux-pm/msg24063.html
用法是, 打上这个PATCH以後, 在KERNEL里面选择上PM_DEBUG， SUSPEND_DEVICE_TIME_DEBUG 这两个选项。
然後
echo 微秒> /sys/power/device_suspend_time_threshold
比如
echo 50000 > /sys/power/device_suspend_time_threshold
注意这里是微秒哦。 。 。 它会把在suspend/resume的时候慢的那些driver打出来，然後你去干掉它。 。
F. 如何查找唤醒android系统
如果在休眠中系统被中断或者其他事件唤醒,接下来的代码就会开始执行,这个唤醒的顺序是和休眠的循序相反的,所以系统设备和总线会首先唤醒，使能系统中断,使能休眠时候停止掉的非启动CPU,以及调用suspend_ops->finish(),而且在suspend_devices_and_enter()函数中也会继续唤醒每个设备,使能虚拟终端,最后调用suspend_ops->end().
在返回到enter_state()函数中的,当suspend_devices_and_enter()返回以后,外设已经唤醒了,但是进程和任务都还是冻结状态,这里会调用suspend_finish()来解冻这些进程和任务,而且发出Notify来表示系统已经从suspend状态退出,唤醒终端.
到这里,所有的休眠和唤醒就已经完毕了,系统继续运行了.
Android系统Suspend和resume的函数流程
Android 休眠(suspend)介绍
在一个打过android补丁的内核中,state_store()函数会走另外一条路,会进入到request_suspend_state()中,这个文件在earlysuspend.c中.这些功能都是android系统加的,后面会对earlysuspend和lateresume进行介绍。
涉及到的文件:
linux_source/kernel/power/main.c
linux_source/kernel/power/earlysuspend.c
linux_source/kernel/power/wakelock.c
特性介绍
1）EarlySuspend
Early suspend是android引进的一种机制,这个机制作用在关闭显示的时候,一些和显示有关的设备,比如LCD背光,重力感应器,触摸屏,这些设备都会关掉，但是系统可能还是在运行状态(这时候还有wakelock)进行任务的处理，例如在扫描SD卡上的文件等.在嵌入式设备中,背光是一个很大的电源消耗，所以android会加入这样一种机制。
2）LateResume
Late Resume是和suspend配套的一种机制,是在内核唤醒完毕开始执行的，主要就是唤醒在EarlySuspend的时候休眠的设备.
当所有的唤醒已经结束以后,用户进程都已经开始运行了,唤醒通常会是以下的几种原因:
来电
如果是来电,那么Modem会通过发送命令给rild来让rild通知WindowManager有来电响应,这样就会远程调用PowerManagerService来写"on"到/sys/power/state来执行lateresume的设备,比如点亮屏幕等.
用户按键用户按键事件会送到WindowManager中,WindowManager会处理这些按键事件,按键分为几种情况,如果案件不是唤醒键(能够唤醒系统的按键)那么WindowManager会主动放弃wakeLock来使系统进入再次休眠,如果按键是唤醒键,那么WindowManger就会调用PowerManagerService中的接口来执行Late Resume.
Late Resume会依次唤醒前面调用了EarlySuspend的设备.
3）WakeLock
Wake Lock在Android的电源管理系统中扮演一个核心的角色.Wake Lock是一种锁的机制,只要有人拿着这个锁，系统就无法进入休眠,可以被用户态程序和内核获得。这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了,内核就会启动休眠的那套机制来进入休眠。
3）AndroidSuspend
当用户写入mem或者standby到/sys/power/state中的时候,state_store()会被调用,然后Android会在这里调用request_suspend_state()而标准的Linux会在这里进入enter_state()这个函数.如果请求的是休眠,那么early_suspend这个workqueue就会被调用,并且进入early_suspend状态。调用request_suspend_state()后在suspend_work_queue工作线程上面注册一个early_suspend_work工作者，
然后又通过staticDECLARE_WORK(early_suspend_work, early_suspend);注册一个工作任务early_suspend。所以系统最终会调用early_suspend函数。
注册加入suspend和resume流程
platform_device_register()-->platform_device_add()-->device_add()-->device_pm_add()-->，最终加入到了dpm_list的链表中，在其中的dpm_suspend和dpm_suspend中通过遍历这个链表来进行查看哪个device中包含suspend和resume项。
系统唤醒和休眠
Kernel层[针对AndroidLinux2.6.28内核]:
其主要代码在下列位置:
Drivers/base /main.c
kernel/power /main.c
kernel/power/wakelock.c
kernel/power/earlysuspend.c
其对Kernel提供的接口函数有
EXPORT_SYMBOL(wake_lock_init);//初始化Suspendlock,在使用前必须做初始化
EXPORT_SYMBOL(wake_lock);//申请lock,必须调用相应的unlock来释放它
static DEFINE_TIMER(expire_timer,expire_wake_locks, 0, 0);//定时时间到，加入到suspend队列中；
EXPORT_SYMBOL(wake_unlock);//释放lock
EXPORT_SYMBOL_GPL(device_power_up);//打开特殊的设备
EXPORT_SYMBOL_GPL(device_power_down);//关闭特殊设备
EXPORT_SYMBOL_GPL(device_resume);//重新存储设备的状态；
EXPORT_SYMBOL_GPL(device_suspend);:保存系统状态，并结束掉系统中的设备；
EXPORT_SYMBOL(register_early_suspend);//注册earlysuspend的驱动
EXPORT_SYMBOL(unregister_early_suspend);//取消已经注册的earlysuspend的驱动
Android的suspent执行流程
函数的流程如下所示：
应用程序通过对/sys/power/state的写入操作可以使系统进行休眠的状态，会调用/kernel/power/main.c中的state_store函数。pm_states包括：
PM_SUSPEND_ON，PM_SUSPEND_STANDBY，PM_SUSPEND_MEM满足的状态。
1）当状态位PM_SUSPEND_ON的状态的时候，request_suspend_state()；当满足休眠的状态的时候，调用request_suspend_state在suspend_work_queue工作线程上创建early_suspend_work队列，queue_work(suspend_work_queue,&early_suspend_work)。
2）然后通过DECLARE_WORK(early_suspend_work,early_suspend);在early_suspend_work工作队列中添加工作任务调用early_suspend，所以early_suspend函数会被调用。
3）early_suspend函数中通过
list_for_each_entry(pos,&early_suspend_handlers, link) {
if (pos->suspend != NULL)
pos->suspend(pos)；
在链表中找注册的suspend函数，这个suspend是early的。early_suspend后面调用wake_unlock函数。语句：wake_unlock(&main_wake_lock);
4）wake_unlock()中调用mod_timer启动expire_timer定时器，当定时时间到了，则执行expire_wake_locks函数，将suspend_work加入到suspend_work_queue队列中，分析到这里就可以知道了early_suspend_work和suspend_work这两个队列的先后顺序了（先执行early，定义一段时间后才执行suspend_work），然后会在suspend_work队列中加入suspend的工作任务，所以wakelock.c中的suspend函数会被调用。
5）suspend调用了pm_suspend，通过判断当前的状态，选择enter_state()，在enter_state中，经过了suspend_prepare，suspend_test和suspend_device_and_enter()，在suspend_device_and_enter中调用dpm_suspend_start()，然后调用dpm_suspend()。
6）dpm_suspend中利用while循环在dpm_list链表查找所有devic，然后调用device_suspend来保存状态和结束系统的设备。到了这里，我们就又可以看见在初始化的时候所看到的队列dpm_list。
dpm_list链表的添加是在device_pm_add中完成，请看上一节中。
Wake Lock
我们接下来看一看wakelock的机制是怎么运行和起作用的,主要关注wakelock.c文件就可以了。
wake lock有加锁和解锁两种状态,加锁的方式有两种,一种是永久的锁住,这样的锁除非显示的放开,是不会解锁的,所以这种锁的使用是非常小心的.第二种是超时锁,这种锁会锁定系统唤醒一段时间,如果这个时间过去了,这个锁会自动解除.
锁有两种类型:
WAKE_LOCK_SUSPEND这种锁会防止系统进入睡眠
WAKE_LOCK_IDLE这种锁不会影响系统的休眠,作用我不是很清楚.
在wakelock中,会有3个地方让系统直接开始suspend(),分别是:
1）在wake_unlock()中,如果发现解锁以后没有任何其他的wakelock了,就开始休眠
2）在定时器都到时间以后,定时器的回调函数会查看是否有其他的wakelock,如果没有,就在这里让系统进入睡眠.
3）在wake_lock()中,对一个wakelock加锁以后,会再次检查一下有没有锁,我想这里的检查是没有必要的,更好的方法是使加锁的这个操作原子化,而 不是繁冗的检查.而且这样的检查也有可能漏掉.
Android于标准Linux休眠的区别
pm_suspend()虽然会调用enter_state()来进入标准的Linux休眠流程，但是还是有一些区别:
当进入冻结进程的时候，android首先会检查有没有wakelock，如果没有,才会停止这些进程，因为在开始suspend和冻结进程期间有可能有人申请了wake lock,如果是这样,冻结进程会被中断.
在suspend_late()中,会最后检查一次有没有wakelock,这有可能是某种快速申请wakelock,并且快速释放这个锁的进程导致的,如果有这种情况,这里会返回错误,整个suspend就会全部放弃.如果pm_suspend()成功了,LOG的输出可以通过在kernelcmd里面增加"no_console_suspend"来看到suspend和resume过程中的log输出。
Android的电源管理主要是通过Wakelock来实现的，在最底层主要是通过如下队列来实现其管理：
LIST_HEAD(dpm_list);
系统正常开机后进入到AWAKE状态,，Backlight会从最亮慢慢调节到用户设定的亮度,系统screenoff timer(settings->sound & display-> Display settings ->Screen timeout)开始计时，在计时时间到之前，如果有任何的activity事件发生,如Touchclick, keyboard pressed等事件,则将Resetscreen off timer, 系统保持在AWAKE状态.如果有应用程序在这段时间内申请了Fullwake lock,那么系统也将保持在AWAKE状态,除非用户按下powerkey.在AWAKE状态下如果电池电量低或者是用AC供电screenoff timer时间到并且选中Keepscreen on while pluged in选项,backlight会被强制调节到DIM的状态。
如果Screenoff timer时间到并且没有Fullwake lock或者用户按了powerkey,那么系统状态将被切换到NOTIFICATION,并且调用所有已经注册的early_suspend_handlers函数,通常会把LCD和Backlight驱动注册成earlysuspend类型,如有需要也可以把别的驱动注册成earlysuspend,这样就会在第一阶段被关闭.接下来系统会判断是否有partialwake lock acquired, 如果有则等待其释放,在等待的过程中如果有useractivity事件发生,系统则马上回到AWAKE状态;如果没有partialwake lock acquired, 则系统会马上调用函数pm_suspend关闭其它相关的驱动,让CPU进入休眠状态。
系统在Sleep状态时如果检测到任何一个Wakeupsource,则CPU会从Sleep状态被唤醒,并且调用相关的驱动的resume函数,接下来马上调用前期注册的earlysuspend驱动的resume函数,最后系统状态回到AWAKE状态.这里有个问题就是所有注册过earlysuspend的函数在进Suspend的第一阶段被调用可以理解,但是在resume的时候,Linux会先调用所有驱动的resume函数,而此时再调用前期注册的earlysuspend驱动的resume函数有什么意义呢?个人觉得android的这个earlysuspend和lateresume函数应该结合Linux下面的suspend和resume一起使用,而不是单独的使用一个队列来进行管理。
G. Linux内核睡眠唤醒调试
本文基于 RockPI 4A 单板 Debian 系统 Linux4.4 内核介绍下睡眠唤醒（ suspend/resume ）的一些调试方法。
1、关闭串口睡眠
在Linux内核睡眠过程中，会先调用 suspend_console() 函数使串口进入睡眠状态，这样会导致后续设备驱动的睡眠过程不可见。可以在boot启动参数中增加 no_console_suspend 参数，显示设备驱动睡眠日志。
2、修改串口日志等级
修改串口日志打印等级，显示更多调试信息。
3、打开设备睡眠唤醒时间
设置 pm_print_times 参数，可以显示设备驱动睡眠唤醒时间，方便调试时查看哪个函数处理占用时间过长。
在调试Linux内核睡眠唤醒功能时，可以使用 RTC 做唤醒源，在系统睡眠5秒后，自动唤醒系统。
在 arch/arm64/configs/rockchip_linux_defconfig 文件中配置宏 CONFIG_PM_TEST_SUSPEND 。
唤醒日志如下：