【电源管理】一个中断wakeup system相关的问题
本文是原「蜗窝讨论区」的历史存档（2016-05-16），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。
最近有个问题比较疑惑： 如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。 还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？） 对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~
时间为贵 写道： 最近有个问题比较疑惑： 如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。 还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？） 对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~
这两个方法，做的是同一件事情，都是控制“request line和irq controller之间的联系”。 IRQF_NO_SUSPEND是旧方法； enable_irq_wake是新方法。 之所以所有的driver都调用这两个接口，有两种可能：一是为兼容；而是不太理解，为保险起见，都调用。
“irq controller和CPU之间的联系”是由local_irq_disable控制。
wowo 写道：
时间为贵 写道： 最近有个问题比较疑惑： 如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。 还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？） 对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~
这两个方法，做的是同一件事情，都是控制“request line和irq controller之间的联系”。 IRQF_NO_SUSPEND是旧方法； enable_irq_wake是新方法。 之所以所有的driver都调用这两个接口，有两种可能：一是为兼容；而是不太理解，为保险起见，都调用。
“irq controller和CPU之间的联系”是由local_irq_disable控制。
如果IRQF_NO_SUSPEND和enable_irq_wake的作用都是保留“request line”到“irq controller”之间的联系而local_irq_disable是断开“irq controller”到“CPU”之间的联系的话，那么在system suspend过程中，最后阶段在disable noboot cpus后会调用arch_suspend_disable_irqs-->local_irq_disable(,这不是一样断开了和cpu的联系了么，那cpu还如何感知wakeup source产生的irq呢？看linuxer曾说过controller和CPU之间除了irq/fiq还有wakeup信号，此时是controller只对CPU传递wakeup信号，直到cpu local_irq_enable后响应对应irq的handler吗？
时间为贵 写道：
wowo 写道：
时间为贵 写道： 最近有个问题比较疑惑： 如果某个driver希望自己的device具备wakeup system的能力，除掉电气特性上具备该能力外，是否还需要同时具备下列两个条件： 1. request_irq时加入IRQF_NO_SUSPEND flag; 2. 调用enable_irq_wake接口。 还是说只要其中一个满足就可以？我看了下基本上所有的driver都会同时调用这两个接口，那么如果必须上述两个条件都成立，是否可以理解为： a. IRQF_NO_SUSPEND控制着request line和irq controller之间的联系； b. enable_irq_wake控制着irq controller和CPU之间的联系。（local_irq_disable断掉的是irq controller和CPU之间的联系么？） 对硬件不了解，想了好久，瞅代码也没瞅太明白啊，各位解惑~~
这两个方法，做的是同一件事情，都是控制“request line和irq controller之间的联系”。 IRQF_NO_SUSPEND是旧方法； enable_irq_wake是新方法。 之所以所有的driver都调用这两个接口，有两种可能：一是为兼容；而是不太理解，为保险起见，都调用。
“irq controller和CPU之间的联系”是由local_irq_disable控制。
如果IRQF_NO_SUSPEND和enable_irq_wake的作用都是保留“request line”到“irq controller”之间的联系而local_irq_disable是断开“irq controller”到“CPU”之间的联系的话，那么在system suspend过程中，最后阶段在disable noboot cpus后会调用arch_suspend_disable_irqs-->local_irq_disable(,这不是一样断开了和cpu的联系了么，那cpu还如何感知wakeup source产生的irq呢？看linuxer曾说过controller和CPU之间除了irq/fiq还有wakeup信号，此时是controller只对CPU传递wakeup信号，直到cpu local_irq_enable后响应对应irq的handler吗？
是的。
多谢版主的耐心解答~~~