On Tuesday, August 10, 2010, Kevin Hilman wrote: > When using runtime PM in combination with CPUidle, the runtime PM > transtions of some devices may be triggered during the idle path. > Late in the idle sequence, interrupts will likely be disabled when > runtime PM for these devices is initiated. > > Currently, the runtime PM core assumes methods are called with > interrupts enabled. However, if it is called with interrupts > disabled, the internal locking unconditionally enables interrupts, for > example: > > pm_runtime_put_sync() Please don't use that from interrupt context. There's pm_runtime_put() exactly for this purpose that puts the _idle() call into a workqueue. > __pm_runtime_put() > pm_runtime_idle() > spin_lock_irq() > __pm_runtime_idle() > spin_unlock_irq() <--- interrupts unconditionally enabled That's because __pm_runtime_idle() has to be called from process context. > dev->bus->pm->runtime_idle() > spin_lock_irq() > spin_unlock_irq() Thanks, Rafael -- 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
