大家好，我是本期栏目编辑小友，现在为大家讲解怎样对Linux系统休眠（System Suspend）和设备中断处理问题。
一、设备IRQ暂停和恢复。
本节主要解决这样一个问题：系统休眠时如何挂起设备中断(IRQ)？在从休眠中醒来的过程中，如何恢复设备的IRQ？
一般来说，在系统挂起过程的后期，每个设备的IRQ(中断请求线)都会被禁用。具体时间点在每个设备的后期挂起阶段之后。代码如下(删除部分无关代码):
静态int suspend _ enter(suspend _ state _ t状态，bool *唤醒)
{……
错误=DPM _ SUSPEND _ late(PMSG _ SUSPEND)；-后期暂停阶段。
错误=platform_suspend_prepare_late(状态)；
以下代码禁用每个设备的irq。
error=DPM _ SUSPEND _ no IRQ(PMSG _ SUSPEND)；-进入noirq阶段。
错误=platform _ suspend _ prepare _ no IRQ(状态)；
……
}
在dpm_suspend_noirq函数中，对于系统中的每个设备，在设备noirq的情况下，将依次调用device_suspend_noirq来执行suspend回调函数。当然，在此之前，将调用suspend _ device _ irqs函数来禁用所有设备的irq。
原因如下：在每个设备驱动程序完成延迟挂起后，这些挂起的设备应该不会再次触发中断。如果有些设备没有正确挂起，那么我们最好的策略就是屏蔽设备的irq，以防止中断被提交。另外，在过去的代码中，我们没有很好地处理设备共享IRQ的情况，出现了这样一个问题：共享IRQ的设备完成挂起后，如果出现中断触发，那么设备驱动的中断处理程序就没有准备好。在某些情况下，中断处理程序会访问挂起设备的IO地址空间，从而导致不可预测的问题。这些问题很难调试，所以我们引入了suspend_device_irqs()和device noirq阶段的回调函数。
在系统恢复过程中，在每个设备的早期恢复过程之前，将重新打开每个设备的IRQ。具体代码如下(删除部分无关代码):
staTIc int suspend _ enter(suspend _ state _ t状态，bool *唤醒)
{……
platform_resume_noirq(状态)；-首先，执行noirq阶段的恢复。
DPM _ RESUME _ no IRQ(PMSG _ RESUME)；-irq将在此恢复，然后进入早期恢复阶段。
platform_resume_early(状态)；
DPM _ RESUME _ early(PMSG _ RESUME)；
……}
在dpm_resume_noirq函数中，调用每个设备驱动程序的noirq回调，之后调用resume _ device _ irqs函数，完成每个设备irq的使能。
第二，关于IRQF_NO_SUSP。
END Flag当然，有些中断需要在整个系统的suspend-resume过程中（包括在noirq阶段，包括将nonboot CPU推送到offline状态以及系统resume后，将其重新设置为online的阶段）保持能够触发的状态。一个简单的例子就是TImer中断，此外IPI以及一些特殊目的设备中断也需要如此。
在中断申请的时候，IRQF_NO_SUSPEND flag可以用来告知IRQ subsystem，这个中断就是上一段文字中描述的那种中断：需要在系统的suspend-resume过程中保持enable状态。有了这个flag，suspend_device_irqs并不会disable该IRQ，从而让该中断在随后的suspend和resume过程中，保持中断开启。当然，这并不能保证该中断可以将系统唤醒。如果想要达到唤醒的目的，请调用enable_irq_wake。
需要注意的是：IRQF_NO_SUSPEND flag影响使用该IRQ的所有外设（一个IRQ可以被多个外设共享，不过ARM中不会这么用）。如果一个IRQ被多个外设共享，并且各个外设都注册了对应的interrupt handler，如果其一在申请中断的时候使用了IRQF_NO_SUSPEND flag，那么在系统suspend的时候（指suspend_device_irqs之后，按理说各个IRQ已经被disable了），所有该IRQ上的各个设备的interrupt handler都可以被正常的被触发执行，即便是有些设备在调用request_irq(或者其他中断注册函数)的时候没有设定IRQF_NO_SUSPEND flag。正因为如此，我们应该尽可能的避免同时使用IRQF_NO_SUSPEND 和IRQF_SHARED这两个flag。
三、系统中断唤醒接口：enable_irq_wake() 和 disable_irq_wake()
有些中断可以将系统从睡眠状态中唤醒，我们称之“可以唤醒系统的中断”，当然，“可以唤醒系统的中断”需要配置才能启动唤醒系统这样的功能。这样的中断一般在工作状态的时候就是作为普通I/O interrupt出现，只要在准备使能唤醒系统功能的时候，才会发起一些特别的配置和设定。
这样的配置和设定有可能是和硬件系统（例如SOC）上的信号处理逻辑相关的，我们可以考虑下面的HW block图：
外设的中断信号被送到“通用的中断信号处理模块”和“特定中断信号接收模块”。正常工作的时候，我们会turn on“通用的中断信号处理模块”的处理逻辑，而turn off“特定中断信号接收模块” 的处理逻辑。但是，在系统进入睡眠状态的时候，有可能“通用的中断信号处理模块”已经off了，这时候，我们需要启动“特定中断信号接收模块”来接收中断信号，从而让系统suspend-resume模块（它往往是suspend状态时候唯一能够工作的HW block了）可以正常的被该中断信号唤醒。一旦唤醒，我们最好是turn off“特定中断信号接收模块”，让外设的中断处理回到正常的工作模式，同时，也避免了系统suspend-resume模块收到不必要的干扰。
IRQ子系统提供了两个接口函数来完成这个功能：enable_irq_wake()函数用来打开该外设中断线通往系统电源管理模块（也就是上面的suspend-resume模块）之路，另外一个接口是disable_irq_wake()，用来关闭该外设中断线通往系统电源管理模块路径上的各种HW block。
调用了enable_irq_wake会影响系统suspend过程中的suspend_device_irqs处理，代码如下：
staTIc bool suspend_device_irq(struct irq_desc *desc)
{
……
if (irqd_is_wakeup_set(&desc->irq_data)) {
irqd_set(&desc->irq_data, IRQD_WAKEUP_ARMED);
return true;
}
省略Disable 中断的代码
}
也就是说，一旦调用enable_irq_wake设定了该设备的中断作为系统suspend的唤醒源，那么在该外设的中断不会被disable，只是被标记一个IRQD_WAKEUP_ARMED的标记。对于那些不是wakeup source的中断，在suspend_device_irq 函数中会标记IRQS_SUSPENDED并disable该设备的irq。在系统唤醒过程中（resume_device_irqs），被diable的中断会重新enable。
当然，如果在suspend的过程中发生了某些事件（例如wakeup source产生了有效信号），从而导致本次suspend abort，那么这个abort事件也会通知到PM core模块。事件并不需要被立刻通知到PM core模块，一般而言，suspend thread会在某些点上去检查pending的wakeup event。
在系统suspend的过程中，每一个来自wakeup source的中断都会终止suspend过程或者将系统唤醒（如果系统已经进入suspend状态）。但是，在执行了suspend_device_irqs之后，普通的中断被屏蔽了，这时候，即便HW触发了中断信号也无法执行其interrupt handler。作为wakeup source的IRQ会怎样呢？虽然它的中断没有被mask掉，但是其interrupt handler也不会执行（这时候的HW Signal只是用来唤醒系统）。唯一有机会执行的interrupt handler是那些标记IRQF_NO_SUSPEND flag的IRQ，因为它们的中断始终是enable的。当然，这些中断不应该调用enable_irq_wake进行唤醒源的设定。
四、Interrupts and Suspend-to-Idle
Suspend-to-idle (也被称为"freeze" 状态)是一个相对比较新的系统电源管理状态，相关代码如下：
staTIc int suspend_enter(suspend_state_t state, bool *wakeup)
{
……
各个设备的late suspend阶段
各个设备的noirq suspend阶段
if (state == PM_SUSPEND_FREEZE) {
freeze_enter();
goto Platform_wake;
}
……
}
Freeze和suspend的前面的操作基本是一样的：首先冻结系统中的进程，然后是suspend系统中的形形色色的device，不一样的地方在noirq suspend完成之后，freeze不会disable那些non-BSP的处理器和syscore suspend阶段，而是调用freeze_enter函数，把所有的处理器推送到idle状态。这时候，任何的enable的中断都可以将系统唤醒。而这也就意味着那些标记IRQF_NO_SUSPEND（其IRQ没有在suspend_device_irqs过程中被mask掉）是有能力将处理器从idle状态中唤醒（不过，需要注意的是：这种信号并不会触发一个系统唤醒信号），而普通中断由于其IRQ被disable了，因此无法唤醒idle状态中的处理器。
那些能够唤醒系统的wakeup interrupt呢？由于其中断没有被mask掉，因此也可以将系统从suspend-to-idle状态中唤醒。整个过程和将系统从suspend状态中唤醒一样，唯一不同的是：将系统从freeze状态唤醒走的中断处理路径，而将系统从suspend状态唤醒走的唤醒处理路径，需要电源管理HW BLOCK中特别的中断处理逻辑的参与。
五、IRQF_NO_SUSPEND 标志和enable_irq_wake函数不能同时使用
针对一个设备，在申请中断的时候使用IRQF_NO_SUSPEND flag，又同时调用enable_irq_wake设定唤醒源是不合理的，主要原因如下：
1、如果IRQ没有共享，使用IRQF_NO_SUSPEND flag说明你想要在整个系统的suspend-resume过程中（包括suspend_device_irqs之后的阶段）保持中断打开以便正常的调用其interrupt handler。而调用enable_irq_wake函数则说明你想要将该设备的irq信号设定为中断源，因此并不期望调用其interrupt handler。而这两个需求明显是互斥的。
2、IRQF_NO_SUSPEND 标志和enable_irq_wake函数都不是针对一个interrupt handler的，而是针对该IRQ上的所有注册的handler的。在一个IRQ上共享唤醒源以及no suspend中断源是比较荒谬的。
不过，在非常特殊的场合下，一个IRQ可以被设定为wakeup source，同时也设定IRQF_NO_SUSPEND 标志。为了代码逻辑正确，该设备的驱动代码需要满足一些特别的需求。
标签：
版权声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢您的支持与理解。