Messages in this thread | | | Date | Fri, 11 Nov 2016 11:40:42 -0800 | From | Brian Norris <> | Subject | Re: [PATCH] PM / wakeirq: report wakeup events in dedicated wake-IRQs |
| |
On Fri, Nov 11, 2016 at 08:47:54AM -0800, Tony Lindgren wrote: > But sounds like the threaded IRQ is not your concern and you mostly
Right, threaded is OK for this; it's not performance critical. It just highlighted the fact that its completion is not synchronized with anything.
> care about getting the right time for the wake up interrupt.
Not "time", per se, but blame. But that blame is timing related: if it comes after the system finished resuming, then it's useless, since user-space won't know to come back and check later.
> The wakeup interrupt controller knows something happened earlier, > so maybe it could report that time if queried somehow?
Sort of. We have /sys/power/pm_wakeup_irq already. But it's really less useful to get IRQ-level stats for this, than to get device info. AFAICT, there's no machine-readable association between IRQs and devices; the best you can get is by parsing the names in /proc/interrupts.
Or, if we really want to say that's sufficient, then maybe we should kill all the device-level wakeup stats in sysfs... (Is that what the flamewar was all about? I hope I'm not poking the hornet's nest.)
BTW, for context, I'm working on using dev_pm_set_dedicated_wake_irq() for a Wifi driver which supports out-of-band (e.g., GPIO-based) wakeup. I see it's used in the I2C core, but the I2C code never actually calls dev_pm_enable_wake_irq(). So while I think I can use this API OK for my Wifi driver (calling dev_pm_{en,dis}able_wake_irq() at system suspend/resume), I'm not sure this will help the I2C case.
The more I look at this API, the more I'm confused, especially about its seeming dependence on runtime PM.
Brian
| |