>> Not following, sorry. if you use pm_runtime functions and it so happens >> that the resume already started, then those routines would wait for the >> resume to complete. > yes that is true, > > TBH, I was trying to reproduce the issue since morning to collect some > traces but no luck so far, I hit these issues pretty much rarely. Now > code has changed since few months back am unable to reproduce this > anymore. Or it might be just the state of code I had while writing this up. > > But when I hit the issue, this is how it looks like: > > 1. IRQ Wake interrupt resume parent. > > 2. parent is in middle of resuming > > 3. Slave Pend interrupt in controller fired up > > 4. because of (3) child resume is requested and then the parent resume > blocked on (2) to finish. > > 5. from (2) we also trying to resume child. > > 6. (5) is blocked on (4) to finish which is blocked on (2) to finish > > we are dead locked. Only way for me to avoid dead lock was to wake the > child up after IRQ wake interrupts. Maybe a red-herring, but we're seen cases like this where we called pm_runtime_get_sync() while resuming, that didn't go so well. I would look into the use of _no_pm routines if you are already trying to resume.
