[v9 PATCH 4/9]: x86: refactor x86 idle power management code and remove all instances of pm_idle.
Arun R Bharadwaj
arun at linux.vnet.ibm.com
Mon Oct 26 18:55:50 EST 2009
* Pavel Machek <pavel at ucw.cz> [2009-10-23 18:07:11]:
> On Fri 2009-10-16 15:13:08, Arun R Bharadwaj wrote:
> > * Arun R Bharadwaj <arun at linux.vnet.ibm.com> [2009-10-16 15:08:50]:
> >
> > This patch cleans up x86 of all instances of pm_idle.
> >
> > pm_idle which was earlier called from cpu_idle() idle loop
> > is replaced by cpuidle_idle_call.
> >
> > x86 also registers to cpuidle when the idle routine is selected,
> > by populating the cpuidle_device data structure for each cpu.
> >
> > This is replicated for apm module and for xen, which also used pm_idle.
> >
> >
> > Signed-off-by: Arun R Bharadwaj <arun at linux.vnet.ibm.com>
> > ---
> > arch/x86/kernel/apm_32.c | 55 ++++++++++++++++++++++++-
> > arch/x86/kernel/process.c | 90 ++++++++++++++++++++++++++++++++----------
> > arch/x86/kernel/process_32.c | 3 -
> > arch/x86/kernel/process_64.c | 3 -
> > arch/x86/xen/setup.c | 40 ++++++++++++++++++
> > drivers/acpi/processor_core.c | 9 ++--
> > drivers/cpuidle/cpuidle.c | 16 +++++--
> > 7 files changed, 182 insertions(+), 34 deletions(-)
> ...
> > +static int local_idle_loop(struct cpuidle_device *dev, struct cpuidle_state *st)
> > +{
> > + ktime_t t1, t2;
> > + s64 diff;
> > + int ret;
> > +
> > + t1 = ktime_get();
> > + local_idle();
> > + t2 = ktime_get();
> > +
> > + diff = ktime_to_us(ktime_sub(t2, t1));
> > + if (diff > INT_MAX)
> > + diff = INT_MAX;
> > + ret = (int) diff;
> > +
> > + return ret;
> > +}
>
> So we get this routine essentially 3 times. Is there no way to share
> the code?
>
We can move this code to a common place, but that would mean exporting
the idle function pointer to be called from within this routine, which
is exactly what we wanted to avoid.
Any suggestions are welcome.
arun
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
More information about the Linuxppc-dev
mailing list