蜗窝科技

@linuxer：前公司的一种实现，没有公开资料。。。 secure watchdog和bus error都配置成了fiq，在secure mode处理。：）

@buyit：先标记一下，陪孩子玩了一天，累死了，脑袋转不动了，明天再理解。anyway，多谢分享！

@wowo：说说我的理解。 wakeup source，wakeup event 感觉名字起的不好。 1，这里就涉及到wakeup的意思了，何为wakeup？我的理解只有系统进入深度睡眠后（一般主晶振停止震动，程序也不跑了），把系统唤醒才叫wakeup。 2，调用device_init_wakeup()，以及产生wakeup event，根本无法把系统从深度睡眠唤醒，把系统从深度睡眠唤醒一般需要中断产生。 而wakeup souce 产生wakeup event的目的不是把系统从深度睡眠唤醒，而是防止系统进入深度睡眠。 基于以上两点。我感觉wakupe souce以及wakeup event名字修改blocksuspend source，blocksuspend event更好。 不知我理解是否正确。 另外 看到好些驱动只是调用device_init_wakeup() -- ，调用这个的一一般会调用pm_stay_awake产生wakup event事件。或者在配合device_can_wakup使用。

@buyit：其实你没有给定具体的应用场景，我不敢说是“对于软硬件最好的设计”，可以肯定的说：你的方案是一个比较通用的设计。 假设你的处理器想使用在传感器网络的，这样场景一般是使用纽扣电池的，而且你期望你的CPU可以在一个纽扣电池的情况下，可以使用1~2年的时候，这时候，所有的设计都是围绕的如何降低功耗来进行，这时候，你是不是想要在idle的时候turn off那个HW timer？当然，我这里描述的内容可能不符合你说的场景，我只是举一个例子而已

@buyit：你说的这个secure watchdog的例子我到时很感兴趣，能否给些具体的信息？什么CPU，我打算去看看它的datasheet PS：bus error是属于IRQ中断吗？感觉好像是其他某种类型的exception

@buyit：IRQF_NOAUTOEN这个flag绝非为“普通”设备而打造，也不是给那些“文艺”类型的设备使用，它是为那些“2B”设备而产生的。这些设备会产生spurious interrupt，撰写driver的时候需要： 1、申请中断的时候不要打开中断 2、当期待中真正中断要来的时候调用enable_irq 3、处理完成后disable之 普通的request_irq不能满足这类奇葩设备的要求

@quote：如果系统用了no_hz,有一个周期性的tick存在，这个tick的周期一般是多少？ ---------------------------------------------------------------------- tick的周期设定和是否配置了NO HZ无关，一般而言，普通的嵌入式系统会设定HZ=100，对于服务器平台，缺省设定为1000. 如果用了no_hz之后，周期性tick仍然是100hz，一旦idle进入了最深的级别，local timer被停止了，这时候有一个广播的timer来负责给idle 的cpu提供timer信号？是否可以理解为即使CPU进入了最深级别的idle，广播timer仍然会以100hz的频率来唤醒CPU？ ------------------------------------------------------------------------ 不是。1~2个星期之内会有一份文档为您解惑，敬请期待，呵呵~~~

@quote：在内核切换到tickless之后，仍然会创建一个sched timer。如果系统接下来进入了idle模式，这个sched timer在文章介绍是会被停止的，既然停止了这个周期性的timer，那么假设系统在1分钟之内都没有其它timer到期，系统1分钟都不退出idle？ ----------------------------------------------------- 如果也没有其他中断触发的情况下（例如用户按下按键、以太网收到数据），那么是的，系统1分钟都不退出idle idle线程被执行到的那个瞬间，代表所有其它线程都主动放弃了CPU，都在等待某种信号？ ------------------------------------------------------------ 是的。当然我理解你这里说的“信号”包括：等待signal、阻塞在I/O上、等待timer到期等等 是否有可能其它线程只是运行时间过长，被调度器剥夺了CPU资源，从而轮到idle线程暂时运行一下？ ----------------------------------------------- 不会，idle进程不参与时间片的运算，只要有进程是runnable的（更准确的说法是对于n个cpu core的系统，只要有n个进程是runnable的），idle是不可能运行到的。 在我看来，系统中所有的线程，不管它的优先级有多低，也不管高优先级的线程有多霸道一直占着CPU不放，调度器始终会保障低优先级的线程有机会运行一小会的，是吗？ --------------------------------------------------------- 不是，对于实时进程，只要它是可执行状态，那么normal进程是不会有机会执行到的。调度算法不是一两句可以将清楚的，我就不赘述了。 总之文中的那句话“sched timer会被停掉，因此，周期性的HW timer不会再来，这时候将cpu从idle中唤醒的只能是和实际上系统中的hrtimer中的那个最近的超期时间有关” 以及回答里的这句话“无论cpuidle的级别深或者不深，cpu都会每秒被timer irq唤醒100次” 是有矛盾的。 ------------------------------------------------------------ 我的原文是这样的：在有tick的内核中，每个cpu core上的swapper进程在被调度到的时候都会控制本cpu core进入idle状态，无论cpuidle的级别深或者不深，cpu都会每秒被timer irq唤醒100次。 我这里强调的是“在有tick的内核中”，也就是说没有配置NO HZ的情况。 对于dynamic tick，当没有执行idle进程的时候，其tick的情况和传统的周期性tick内核行为是一致的，而调度到idle进程执行的时候，会停掉sched timer，从而禁止了周期性tick的到来

如下copy过来后忘记修改了？呵呵。 dpm_suspend，执行所有设备的“->suspend() callback(s)”，其内部动作和dpm_prepare类似： 1）遍历dpm_list，依次取出挂在该list中的device指针。 -- 遍历dpm_prepared_list 2）调用内部接口device_suspend，执行实际的prepare动作。 --执行suspend动作

mark ^_^