Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Thu, 19 Aug 2010, Kevin Hilman wrote: > >> > 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. >> >> Why? > > Because that's how the Runtime PM framework was designed. Drivers > expect interrupts to be enabled when their runtime PM callbacks are > invoked. And the framework internally depends on it as well. > >> > In fact, it's hard to see what could cause this to happen at all. >> >> As I mentioned in the changelog, this happens when trying to use runtime >> PM in combination with CPUidle. As has been suggested elsewhere[1], >> there is a need to do runtime PM on some devices in combination with CPU >> idle transitions managed by CPUidle. However, late in the idle path, >> at the time we want to manage these IO devices, interrupts are disabled. > > Then it isn't really feasible to use the runtime PM framework for those > devices. Not unless the framework is extended with new functions meant > to be used without interrupts enabled (in which case it doesn't seem to > matter much whether you are in process context or not). > >> Currently, on OMAP, we are already managing the power state of certain >> IO devices along with CPUidle transitions using more brute force >> methods. IMO, using runtime PM for this would be a much cleaner >> approach. The only obstacle is the assumption that the API must be >> called with interrupts enabled. > > That's a big obstacle. Why can't you manage these devices earlier, > while interrupts are still enabled? Indeed, that's a good question. I'm exploring this more thoroughly now. Kevin -- 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
