* Grygorii Strashko <grygorii.strashko@xxxxxx> [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/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
