> 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
0008-runtime-pm-changes.patch
Description: 0008-runtime-pm-changes.patch
