OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
Quoted 7 lines · Grygorii Strashko
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 :)
Quoted 5 lines
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