> Finally, we have omap_sram_idle(): > > > In particular, for USB, while executing SRAM_Idle, is we use pm_runtime > > functions, we see spurious IO-Pad interrupts. > > Your message doesn't specify what PM runtime functions you are executing. > But if those functions are calling mutex_lock(), then they obviously must > not be called from omap_sram_idle() in interrupt context. > > It's not clear from your message why you need to call PM runtime functions > from the idle loop. I'd suggest that you post the problematic code in > question to the list. > USB issue: Please refer to the USB patch attached (will be sent to the list as well in a few minutes) As I mentioned previously, few drivers like GPIO, USB & UART have clock- disable/enable + context save/restore in Idle path(omap_sram_idle()). In particular, I am referring to calling of the functions pm_runtime_put_sync() & pm_runtime_get_sync() for USB around wfi. Now, the following call sequence from omap_sram_idle()will enable IRQs: pm_runtime_put_sync--> __pm_runtime_put--> pm_runtime_idle--> spin_unlock_irq(), __pm_runtime_idle(),--> spin_unlock_irq, spin_unlock_irq The functions pm_runtime_idle() & __ pm_runtime_idle() do not use spin_lock_irqsave & spin_unlock_irqrestore. This leads to enabling of the interrupts in omap_sram_idle unconditionally, which for USB in particular is leading to IO-pad interrupt being triggered which does not come otherwise. To work around this problem, instead of using Runtime APIs, we are using omap_device_enable/disable, which in-turn call to __omap_hwmod_enable/idle Simply put, I am not talking about grabbing a mutex when interrupts are disabled, rather of a scenario where interrupts are getting enabled as a side-effect of calling these functions in omap_sram_idle(). > > - Paul
Attachment:
0008-runtime-pm-changes.patch
Description: 0008-runtime-pm-changes.patch
