On Tue, 10 Aug 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: ... > 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 <p-basak2@xxxxxx> > Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> > --- > 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. There are restrictions on what you're allowed to do with the flags, but I don't remember exactly what they are. In any case, I don't really like this change. It seems that we would be better off preventing the runtime PM calls from occurring in the first place while interrupts are disabled. In fact, it's hard to see what could cause this to happen at all. Alan Stern -- 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
