[PATCH 0/3] Add generic idle notifiers

Todd Poynor toddpoynor at google.com
Thu Jul 7 16:17:48 EDT 2011


On Thu, Jul 07, 2011 at 10:05:10AM -0700, Kevin Hilman wrote:
> Todd Poynor <toddpoynor at google.com> writes:
> 
> > Add notifiers for idle entry and exit, called with IDLE_START when a
> > CPU goes idle and IDLE_END when it goes out of idle, based on the
> > existing idle notifiers for the x86_64 arch.
> >
> > Convert x86_64 to use these notifiers, and call the notifiers on ARM.
> >
> > Convert the ARM LEDs events for idle start/end to these notifiers.
> 
> Is this intended to replace the more general CPU PM notifiers proposed
> by Colin:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/052827.html

This is intended to coexist with the CPU PM notifiers.  The idle
notifiers proposed here are notifying of a change in kernel scheduler
state: the scheduler has no task to run and is entering its "idle
loop", or now has something to run and is exiting idle state.
Things that can use this include power management hints such as the
existing drivers/idle/i7300_idle.c usage, the ARM LEDs idle triggers,
and there's probably other existing potential uses in other arch'es that
I should go track down.

The CPU PM notifiers notify of changes in hardware power state that
affect the CPU and closely associated IP blocks (such as an OMAP
power state transition that causes one or more CPU power domains to
hit OFF).  These changes may be due to cpuidle power state management
when the system is idle, or may be due to suspending or resuming the
system (such as a suspend-to-RAM), or may be due to a CPU hotplug event.
In the case of an idle loop entry, if cpuidle decides it is not
appropriate to change CPU power state (as when insufficient time
remains until next timer expiry to enter such a power state due to
entry and exit latency), there may be no CPU PM notification
generated.  The callbacks for CPU PM notifiers on ARM do things such
as save/restore GIC interrupt controller state and VFP floating-point
coprocessor state.

That's the intent, anyhow, but ideas are welcome, thanks,


Todd



More information about the linux-arm-kernel mailing list