2010/8/11 Kevin Hilman <[email protected]>: > 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()
It is always called from process context, why do you have to disable irq before calling pm_runtime_put_sync? > __pm_runtime_put() > pm_runtime_idle() > spin_lock_irq() > __pm_runtime_idle() > spin_unlock_irq() <--- interrupts unconditionally enabled > dev->bus->pm->runtime_idle() > spin_lock_irq() > spin_unlock_irq() > > Unconditionally enabling interrupts late in the idle sequence is not > desired behavior. To fix, use the save/restore versions of the > spinlock API. > > Reported-by: Partha Basak <[email protected]> > Signed-off-by: Kevin Hilman <[email protected]> > --- > RFC: I'm not crazy about having the 'flags' in struct dev_pm_info, but > since the locks are taken and released in separate functions, this > seems better than changing the function APIs to pass around the flags. > thanks, -- Lei Ming -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
