Re: add lowpower_idle sysctl

[Dominik Brodowski <linux@dominikbrodowski.de>]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Wed, Mar 17, 2004 at 10:40:31PM -0500, Zwane Mwaikambo wrote:
> On Wed, 17 Mar 2004, Andrew Morton wrote:
> 
> > "Kenneth Chen" <kenneth.w.chen@intel.com> wrote:
> > >
> > >  > > Logically it means a sysctl entry in /proc/sys/kernel.
> > >  > Yes, but the *meanings* of the different values of that sysctl need
> > >  > to be defined, and documented.  If lowpower_idle=42 has a totally
> > >  > different meaning on different architectures then that's unfortunate
> > >  > but understandable.  But we should at least enumerate the different
> > >  > values and try to get different architectures to honour `42' in the
> > >  > same way.
> > >
> > >  Writing to sysctl should be a bool, reading the value can be number of
> > >  module currently disabled low power idle.  I think the original intent
> > >  is to use ref count for enabling/disabling.  (granted, we copied the
> > >  code from other arch).

I assume ia64 does idling using the ACPI processor.c driver? If so, couldn't
writing to /proc/acpi/processor/./power be an option?

> > OK, so why not give us:
> >
> > #define IDLE_HALT			0
> > #define IDLE_POLL			1
> > #define IDLE_SUPER_LOW_POWER_HALT	2
> >
> > and so forth (are there any others?).
> >
> > Set some system-wide integer via a sysctl and let the particular
> > architecture decide how best to implement the currently-selected idle mode?
> 
> I'm wondering whether the setting of these magic numbers can't be done
> using cpufreq infrastructure.

I doubt it -- there's no ia64 cpufreq driver anyway, and cpufreq is about
frequency scaling and (sometimes) throttling, but not "idling". And
"idling" is a too different implementation anyways.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]