* Grygorii Strashko [off-list ref] [160308 03:32]:

Yeah. As I mentioned before patches 2/3 will not work.
I've tried to test suspend with diff I posted [1], but I did it only on 
dra7 and am43 where suspend i more simple than on omap3. Also, I worry
that with such approach some irq can be missed (especially edge ones), 
because PRCM irqs will be re-enabled at very late resume stage 
(right before thaw).

Yeah any tests not done with PM on omap3 with the mainline kernel
are clearly incomplete in this case :)

Second option, I see, is to rework PRCM to be threaded IRQ, but in this case
all children IRQs will need to be threaded/nested threaded
(including PCS, legacy OMAP mux, OMAP3 _prcm_int_handle_wakeup/_prcm_int_handle_io).

Are there any objection to convert PCS to threaded IRQ, for example? ;)

For PRCM interrupt, I don't think that can be threaded IRQ as
that thing is firing all the time. The consumers for the chained
PRCM interrupt consumers like PCS could probably use threaded IRQ.
When the PCS interrupts fire, we're already in some sleeper
idle state so the extra latency thre does not matter.

Regards,

Tony

[1] https://patchwork.ozlabs.org/patch/578915/