"Rafael J. Wysocki" <rjw@xxxxxxx> writes: > On Thursday, August 19, 2010, Kevin Hilman wrote: >> "Rafael J. Wysocki" <rjw@xxxxxxx> writes: >> >> > 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. >> >> I'm not using this in interrupt context. I'm using it in process >> context where interrupts are disabled, specifically, the idle thread. >> >> > There's pm_runtime_put() exactly for this purpose that puts the >> > _idle() call into a workqueue. >> * >> If I'm in my CPU's idle path, I don't want to activate a workqueue >> because then I'll no longer be idle. > > Well, what about: > > -> idle > -> check if devices have been suspended > - enter idle if so > - call pm_request_idle() for devices > > The workqueue will activate and put the devices into low-power states and > then your idle callback will be called again, with the devices suspended. The problem with this is that after we leave idle, the decision about which C-state to enter will likely change, which will affect the set of devices that need to be suspended. I'm not sure this will be an entirely predictable process with current CPUidle governors, but it certainly merits some more experiments. 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
