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.
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
