蜗窝科技

@wowo：是的，加了pm_wakeup_event才可以

@yang：sorry,忘了在帖子下面回复了。

从日志里面可以看到ltr559的中断已经被处理了（ltr559_irq_handler），但是handler中schedule了一个thread，而此时系统在suspend的过程中，已经没有机会调度了。所以这种情况irq_enable_wake(irq)和IRQF_NO_SUSPEND是解决不了的。需要使用Wakeup events framework，阻止系统suspend，具体可以参考“http://www.wowotech.net/pm_subsystem/wakeup_events_framework.html”中的描述。

01-01 00:54:39.863 D/PowerManagerNotifier( 866): mGoToSleepBroadcastDone - sendNextBroadcast 01-01 00:29:13.659 V/kernel ( 3449): <6>[ 1836.671959] PM: suspend entry 2014-12-31 16:54:39.872099731 UTC 01-01 00:29:13.659 V/kernel ( 3449): <6>[ 1836.671968] PM: Syncing filesystems ... done. 01-01 00:29:13.672 V/kernel ( 3449): <6>[ 1836.685205] Freezing user space processes ... (elapsed 0.002 seconds) done. 01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.686529] [ALS/PS] ltr559_irq_handler, in 01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.687035] [ALS/PS] ltr559_schedwork, status=0X33 01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.687041] [ALS/PS] ltr559_schedwork, ps interrupt 01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687345] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. 01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687616] [ALS/PS] read_ps_adc_value, ps_val=174 01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687636] [ALS/PS] report_ps_input_event_zte, ps far 01-01 00:29:13.676 V/kernel ( 3449): <6>[ 1836.688350] [ALS/PS] report_ps_input_event_zte, adc_value=174,default_ps_lowthresh=185,default_ps_highthresh=214 01-01 00:29:13.676 V/kernel ( 3449): <6>[ 1836.689101] Suspending console(s) (use no_console_suspend to debug) 01-01 00:29:13.680 V/kernel ( 3449): <6>[ 1836.693195] fb_notifier_callback. 01-01 00:29:13.680 V/kernel ( 3449): <6>[ 1836.693206] mdss_dsi_event_handler: event=7 01-01 00:29:13.681 V/kernel ( 3449): <6>[ 1836.693222] fb_notifier_callback. 01-01 00:29:13.682 V/kernel ( 3449): <6>[ 1836.694800] ltr559_suspend 01-01 00:29:13.699 V/kernel ( 3449): <6>[ 1836.711522] PM: suspend of devices complete after 21.136 msecs 01-01 00:29:13.700 V/kernel ( 3449): <6>[ 1836.713124] PM: late suspend of devices complete after 1.594 msecs 01-01 00:29:13.703 V/kernel ( 3449): <6>[ 1836.715527] PM: noirq suspend of devices complete after 2.396 msecs 01-01 00:29:13.703 V/kernel ( 3449): <6>[ 1836.715532] Disabling non-boot CPUs ... 01-01 00:29:13.705 V/kernel ( 3449): <4>[ 1836.717235] IRQ39 no longer affine to CPU2 01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] CPU0:msm_cpu_pm_enter_sleep mode:3 during suspend 01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] Enabled clocks: 01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] xo_a_clk_src:2:2 [19200000] 01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] bimc_msmbus_a_clk:1:1 [532938752] -> bimc_a_clk:1:1 [532938752] 01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] pcnoc_keepalive_a_clk:1:1 [19200000] -> pcnoc_a_clk:1:1 [19200000 wowo,我遇到一个问题，上述log，系统在suspend过程中ltr559驱动上报了一个消息，但这个消息未及时传递到上层，只能在下一次其他中断源唤醒系统后才处理ltr559的消息。 已经设定了irq_enable_wake(irq);但是没设IRQF_NO_SUSPEND标志。我加上IRQF_NO_SUSPEND标志会有改善吗？ 谢谢

@star：我觉得这才是这个社会的无奈，理想状态下，搞量子物理的一定要比搞嵌入式的挣的钱更多，哪怕他一辈子什么都没搞出来……

已从量子物理转到嵌入式混饭吃...

@wowo：明白了，非常感谢！

@linuxer：我更新了这篇文章的最后一节，结果还真和我们想象的不一样，在cpuidle framework中，进入idle时，是关中断的，因此从idle回来后，只能先回到idle thread，打开中断后，才能执行中断handler。

@ayeu0425：对于那些标准的dts字段，如触发类型，可以让kernel在初始化的时候，帮忙解析，不再需要每个driver都手动调用irq_of_parse_and_map。大概流程如下，供您参考： of_device_alloc num_irq = of_irq_count(np); of_irq_to_resource_table-->of_irq_to_resource-->irq_of_parse_and_map of_irq_map_one irq_create_of_mapping irq_set_irq_type 对于那些需要主动调用irq_of_parse_and_map的场景，一定是irq driver实现的不标准，这不是一个好的设计。

博主，还想请教你一个问题，因为也看到你写device tree的文章。 对于一个具体的中断，例如 interrupt = <0 118 0x4>，它分别描述是中断类型、中断号、中断触发方式。 这个中断触发方式是被使用的？ 比如网卡驱动中有 irq=platform_get_irq(...)【为什么不是irq_of_parse_and_map】,然后request_irq(irq,handler,IRQF_DISABLED,...)。这是怎么确定触发方式是电平触发(0x04)的呢？