PowerOP 2/3: Intel Centrino support

PowerOP 2/3: Intel Centrino support

[Todd Poynor]

Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
notebooks.  These systems run at an operating point comprised of a cpu
frequency and a core voltage.  The voltage could be set from the values
recommended in the datasheets if left unspecified (-1) in the operating
point, as cpufreq does.


Index: linux-2.6.12/arch/i386/Kconfig
===================================================================
--- linux-2.6.12.orig/arch/i386/Kconfig	2005-08-02 23:39:05.000000000 +0000
+++ linux-2.6.12/arch/i386/Kconfig	2005-08-03 01:11:21.000000000 +0000
@@ -1098,6 +1098,7 @@
 endmenu
 
 source "arch/i386/kernel/cpu/cpufreq/Kconfig"
+source "arch/i386/kernel/cpu/powerop/Kconfig"
 
 endmenu
 
Index: linux-2.6.12/arch/i386/kernel/cpu/Makefile
===================================================================
--- linux-2.6.12.orig/arch/i386/kernel/cpu/Makefile	2005-08-02 23:39:05.000000000 +0000
+++ linux-2.6.12/arch/i386/kernel/cpu/Makefile	2005-08-03 01:11:21.000000000 +0000
@@ -17,3 +17,4 @@
 
 obj-$(CONFIG_MTRR)	+= 	mtrr/
 obj-$(CONFIG_CPU_FREQ)	+=	cpufreq/
+obj-$(CONFIG_POWEROP)	+=	powerop/
Index: linux-2.6.12/arch/i386/kernel/cpu/powerop/Kconfig
===================================================================
--- linux-2.6.12.orig/arch/i386/kernel/cpu/powerop/Kconfig	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.12/arch/i386/kernel/cpu/powerop/Kconfig	2005-08-03 01:11:21.000000000 +0000
@@ -0,0 +1,6 @@
+source "drivers/powerop/Kconfig"
+
+config POWEROP_CENTRINO
+       tristate "PowerOP for Intel Centrino Enhanced Speedstep"
+       depends on POWEROP
+       default n
Index: linux-2.6.12/arch/i386/kernel/cpu/powerop/Makefile
===================================================================
--- linux-2.6.12.orig/arch/i386/kernel/cpu/powerop/Makefile	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.12/arch/i386/kernel/cpu/powerop/Makefile	2005-08-03 01:11:21.000000000 +0000
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWEROP_CENTRINO)	+=	powerop-centrino.o
+
Index: linux-2.6.12/arch/i386/kernel/cpu/powerop/powerop-centrino.c
===================================================================
--- linux-2.6.12.orig/arch/i386/kernel/cpu/powerop/powerop-centrino.c	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.12/arch/i386/kernel/cpu/powerop/powerop-centrino.c	2005-08-03 06:41:37.000000000 +0000
@@ -0,0 +1,160 @@
+/*
+ * PowerOP support for Intel Enhanced Speedstep "Centrino" platforms.
+ *
+ * Based heavily on speedstep-centrino.c of cpufreq Copyright (c) 2003
+ * by Jeremy Fitzhardinge <jeremy@goop.org>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/powerop.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/threads.h>
+#include <linux/slab.h>
+
+#include <asm/msr.h>
+#include <asm/processor.h>
+#include <asm/cpufeature.h>
+
+static int
+powerop_centrino_get_point(struct powerop_point *point)
+{
+	unsigned l, h;
+	unsigned cpu_freq;
+
+	rdmsr(MSR_IA32_PERF_STATUS, l, h);
+	if (unlikely((cpu_freq = ((l >> 8) & 0xff) * 100) == 0)) {
+		/*
+		 * On some CPUs, we can see transient MSR values (which are
+		 * not present in _PSS), while CPU is doing some automatic
+		 * P-state transition (like TM2). Get the last freq set 
+		 * in PERF_CTL.
+		 */
+		rdmsr(MSR_IA32_PERF_CTL, l, h);
+		cpu_freq = ((l >> 8) & 0xff) * 100;
+	}
+
+	point->param[POWEROP_CPU + smp_processor_id()] = cpu_freq;
+	point->param[POWEROP_V + smp_processor_id()] = ((l & 0xff) * 16) + 700;
+	return 0;
+}
+
+static int
+powerop_centrino_set_point(struct powerop_point *point)
+{
+	unsigned int msr = 0, oldmsr, h, mask = 0;
+
+	if (point->param[POWEROP_CPU + smp_processor_id()] != -1) {
+		msr |= (point->param[POWEROP_CPU + smp_processor_id()]/100)
+			<< 8;
+		mask |= 0xff00;
+	}
+
+	if (point->param[POWEROP_V + smp_processor_id()] != -1) {
+		msr |= ((point->param[POWEROP_V + smp_processor_id()] - 700)
+			/ 16);
+		mask |= 0xff;
+	}
+
+	rdmsr(MSR_IA32_PERF_CTL, oldmsr, h);
+
+	if (msr == (oldmsr & mask))
+		return 0;
+
+	/* all but 16 LSB are "reserved", so treat them with
+	   care */
+	oldmsr &= ~mask;
+	msr &= mask;
+	oldmsr |= msr;
+	
+	wrmsr(MSR_IA32_PERF_CTL, oldmsr, h);
+	return 0;
+}
+
+#ifdef CONFIG_POWEROP_SYSFS
+static char *powerop_param_names[POWEROP_DRIVER_MAX_PARAMS];
+
+static int __init powerop_centrino_sysfs_init(void)
+{
+	int i;
+
+	for (i = 0; i < NR_CPUS; i++) {
+		if (! (powerop_param_names[POWEROP_CPU + i] = 
+		       kmalloc(5 + i / 10, GFP_KERNEL)) ||
+		    ! (powerop_param_names[POWEROP_V + i] = 
+		       kmalloc(3 + i / 10, GFP_KERNEL)))
+			goto nomem;
+
+		sprintf(powerop_param_names[POWEROP_CPU + i], "cpu%d", i);
+		sprintf(powerop_param_names[POWEROP_V + i], "v%d", i);
+	}
+
+	return 0;
+
+nomem:
+	printk(KERN_ERR "power-centrino malloc failed\n");
+
+	for (i = 0; i < NR_CPUS; i++) {
+		kfree(powerop_param_names[POWEROP_CPU + i]);
+		kfree(powerop_param_names[POWEROP_V + i]);
+	}
+
+	return -ENOMEM;
+}
+#else
+static int __init powerop_centrino_sysfs_init(void)
+{
+	return 0;
+}
+#endif
+
+static struct powerop_driver power_driver_centrino = {
+	.name		= "centrino",
+	.nr_params	= POWEROP_DRIVER_MAX_PARAMS,
+#ifdef CONFIG_POWEROP_SYSFS
+	.param_names    = powerop_param_names,
+#endif
+	.get_point	= powerop_centrino_get_point,
+	.set_point	= powerop_centrino_set_point,
+};
+
+static int __init powerop_centrino_init(void)
+{
+	struct cpuinfo_x86 *cpu = cpu_data;
+	unsigned l, h;
+
+	if (!cpu_has(cpu, X86_FEATURE_EST))
+		return -ENODEV;
+
+	/* Check to see if Enhanced SpeedStep is enabled, and try to
+	   enable it if not. */
+	rdmsr(MSR_IA32_MISC_ENABLE, l, h);
+		
+	if (!(l & (1<<16))) {
+		l |= (1<<16);
+		wrmsr(MSR_IA32_MISC_ENABLE, l, h);
+		
+		/* check to see if it stuck */
+		rdmsr(MSR_IA32_MISC_ENABLE, l, h);
+		if (!(l & (1<<16))) {
+			printk(KERN_INFO "PowerOP: Couldn't enable Enhanced SpeedStep\n");
+			return -ENODEV;
+		}
+	}
+	
+	return powerop_centrino_sysfs_init() || 
+		powerop_driver_register(&power_driver_centrino);
+}
+
+static void __exit powerop_centrino_exit(void)
+{
+	powerop_driver_unregister(&power_driver_centrino);
+}
+
+module_init(powerop_centrino_init);
+module_exit(powerop_centrino_exit);
Index: linux-2.6.12/include/asm-i386/powerop-centrino.h
===================================================================
--- linux-2.6.12.orig/include/asm-i386/powerop-centrino.h	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.12/include/asm-i386/powerop-centrino.h	2005-08-03 01:24:16.000000000 +0000
@@ -0,0 +1,20 @@
+/*
+ * PowerOP support for Intel Enhanced Speedstep "Centrino" platforms.
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __ASM_POWEROP_CENTRINO_H__
+#define __ASM_POWEROP_CENTRINO_H__
+
+#include <linux/threads.h>
+
+#define POWEROP_CPU		0	/* CPU freq in MHz*/
+#define POWEROP_V		NR_CPUS /* core voltage */
+
+#define POWEROP_DRIVER_MAX_PARAMS	2*NR_CPUS	/* max # params */
+
+#endif /* __ASM_POWEROP_CENTRINO_H__ */
Index: linux-2.6.12/include/asm-i386/powerop.h
===================================================================
--- linux-2.6.12.orig/include/asm-i386/powerop.h	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.12/include/asm-i386/powerop.h	2005-08-03 01:23:03.000000000 +0000
@@ -0,0 +1,19 @@
+/*
+ * PowerOP support for i386 platforms.
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __ASM_POWEROP_H__
+#define __ASM_POWEROP_H__
+
+#include <linux/config.h>
+
+#ifdef CONFIG_POWEROP_CENTRINO
+#include <asm/powerop-centrino.h>
+#endif
+
+#endif /* __ASM_POWEROP_H__ */

Re: PowerOP 2/3: Intel Centrino support

[Ingo Molnar]

* Todd Poynor <tpoynor@mvista.com> wrote:

> +static int
> +powerop_centrino_get_point(struct powerop_point *point)
> +{
> +	unsigned l, h;
> +	unsigned cpu_freq;
> +
> +	rdmsr(MSR_IA32_PERF_STATUS, l, h);
> +	if (unlikely((cpu_freq = ((l >> 8) & 0xff) * 100) == 0)) {
> +		/*
> +		 * On some CPUs, we can see transient MSR values (which are
> +		 * not present in _PSS), while CPU is doing some automatic
> +		 * P-state transition (like TM2). Get the last freq set 
> +		 * in PERF_CTL.
> +		 */
> +		rdmsr(MSR_IA32_PERF_CTL, l, h);
> +		cpu_freq = ((l >> 8) & 0xff) * 100;
> +	}
> +
> +	point->param[POWEROP_CPU + smp_processor_id()] = cpu_freq;
> +	point->param[POWEROP_V + smp_processor_id()] = ((l & 0xff) * 16) + 700;
> +	return 0;
> +}

doesnt seem to be SMP-safe, nor PREEMPT-safe. You probably want to do 
the locking in the highlevel functions.

	Ingo

Re: PowerOP 2/3: Intel Centrino support

[Pavel Machek]

Hi!

> Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
> notebooks.  These systems run at an operating point comprised of a cpu
> frequency and a core voltage.  The voltage could be set from the values
> recommended in the datasheets if left unspecified (-1) in the operating
> point, as cpufreq does.

Eh? I thought these are handled okay by cpufreq already? What is
advantage of this over cpufreq?
								Pavel

-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: PowerOP 2/3: Intel Centrino support

[Bruno Ducrot]

On Wed, Aug 10, 2005 at 12:01:33PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
> > notebooks.  These systems run at an operating point comprised of a cpu
> > frequency and a core voltage.  The voltage could be set from the values
> > recommended in the datasheets if left unspecified (-1) in the operating
> > point, as cpufreq does.
> 
> Eh? I thought these are handled okay by cpufreq already? What is
> advantage of this over cpufreq?

ATM I'm wondering what are the pro for those patches wrt current cpufreq
infrastructure (especially cpufreq's notion of notifiers).

I still don't find a good one but I'm surely missing something obvious.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [linux-pm] Re: PowerOP 2/3: Intel Centrino support

[Dave Jones]

On Wed, Aug 10, 2005 at 02:58:48PM +0200, Bruno Ducrot wrote:

 > > > Minimal PowerOP support for Intel Enhanced Speedstep "Centrino"
 > > > notebooks.  These systems run at an operating point comprised of a cpu
 > > > frequency and a core voltage.  The voltage could be set from the values
 > > > recommended in the datasheets if left unspecified (-1) in the operating
 > > > point, as cpufreq does.
 > > 
 > > Eh? I thought these are handled okay by cpufreq already?

It does to some extent.  You can't explicitly set a voltage with
cpufreq, but the low-level drivers will match a voltage to a speed
on chips that we know enough info about.

 > ATM I'm wondering what are the pro for those patches wrt current cpufreq
 > infrastructure (especially cpufreq's notion of notifiers).
 > 
 > I still don't find a good one but I'm surely missing something obvious.

I'm glad I'm not the only one who feels he's too dumb to see
the advantages of this. The added complexity to expose something
that in all cases, we actually don't want to expose seems a little
pointless to me.

For example, most of the x86 drivers, if you set a speed, and then
start fiddling with the voltage, you can pretty much guarantee
you'll crash within the next few seconds.  They have to match,
or at the least, be within a very small margin.

Given how long its taken us to get sane userspace parts for cpufreq,
I'm loathe to changing the interfaces yet again unless there's
a clear advantage to doing so, as it'll take at least another 12 months
for userspace to catch up.

		Dave

Re: PowerOP 2/3: Intel Centrino support

[Todd Poynor]

Bruno Ducrot wrote:
  > ATM I'm wondering what are the pro for those patches wrt current cpufreq
> infrastructure (especially cpufreq's notion of notifiers).
> 
> I still don't find a good one but I'm surely missing something obvious.

This is lower layer than cpufreq, intended for use by cpufreq (and 
potentially DPM and other frameworks, although moving embedded to use 
cpufreq is certainly an option) to do the actual hardware modifications 
at the lowest layer.  There are no notifiers et al because the 
higher-layer frameworks handle that portion of it.  More on that in a 
moment.

The main goal is to open up interfaces to operating points comprised of 
arbitrary power parameters, as an alternative to the "cpu frequency" 
parameter that cpufreq is designed around.  In the desktop/server world 
this may not be a high concern for two reasons: (1) although various 
folks do want to manage voltages separately (namely so-called 
"undervolting"), in most cases the safe answer is to stick with a 
voltage preprogrammed into cpufreq that matches what the silicon vendor 
as validated and supports; (2) various additional clocks, dividers, etc. 
potential power parameters might exist in the hardware, but interfaces 
for software control are often not readily available, and the associated 
parameters are typically set once by the BIOS at boot time (possibly 
with a menu to allow you override the defaults).

In the embedded world, however, silicon vendors typically produce 
hardware that are run by, and specify validated operating points that 
are comprised of, 6-7 basic parameters (clocks, voltages, dividers, 
etc.), and in many cases it is useful to manage all these parameters for 
additional battery savings at runtime (and these systems are often 
powered by much smaller batteries than the notebooks powered by 
desktop-class processors, and so more aggressive reductions in power 
consumption may be pursued).  Similar interfaces are already in use for 
managing such hardware, with benefits that largely depend on the 
capabilities of the hardware (in the case of the IBM PowerPC 405LP for 
which it was originally developed this was pretty extensively studied).

It is possible, of course, to choose operating points according to cpu 
frequency and hardcode the settings of other power parameters to match, 
restricting the choices for the other parameters.  There are, however, 
power consumption and performance (primarily latency of transition 
between operating points) advantages to being able to choose memory bus 
speeds, core PLL speeds, voltages (yes, some embedded platforms do allow 
this to be chosen within limits imposed by other clock speeds), etc. 
The embedded hardware designers could probably express this more 
eloquently than I can.

A secondary goal is to separate the code to perform platform-specific 
hardware modifications from the upper layers which by necessity carry 
various assumptions that may not be appropriate for all situations.  The 
notifiers are one example of this: DPM typically minimizes use of 
notifiers and requires notifiers to be able to operate in interrupt and 
in idle loop context, due to those additional situations in which DPM 
manages power parameters.

-- 
Todd

Re: [linux-pm] Re: PowerOP 2/3: Intel Centrino support

[Todd Poynor]

Dave Jones wrote:
> I'm glad I'm not the only one who feels he's too dumb to see
> the advantages of this. The added complexity to expose something
> that in all cases, we actually don't want to expose seems a little
> pointless to me.
> 
> For example, most of the x86 drivers, if you set a speed, and then
> start fiddling with the voltage, you can pretty much guarantee
> you'll crash within the next few seconds.  They have to match,
> or at the least, be within a very small margin.

I've attempted to extoll the benefits of adding these interfaces in 
previous emails, and if after that it still seems mystifying why anybody 
would want to do this then I'll take the heat for doing a lousy job of 
extolling.  I've also admitted that it is primarily of use in 
embedded-specific hardware, and of less use in x86 and in desktop/server 
usage for various reasons (unless it turns out there's some fantastic 
savings to be had in modifying common x86 bus speeds independently of 
cpu speed, which seems unlikely).  In the case of x86, undervolting is 
in practice by some folks, but yes it is risky and support for it in the 
basic interfaces probably shouldn't be a high priority.

> Given how long its taken us to get sane userspace parts for cpufreq,
> I'm loathe to changing the interfaces yet again unless there's
> a clear advantage to doing so, as it'll take at least another 12 months
> for userspace to catch up.

Just to be clear, there are no cpufreq userspace interface changes 
required by this, it simply occupies the bottom layer of code that 
modifies platform power registers etc.  The same speed/policy/governor 
etc. interfaces are used to specify the cpu speed.  Interfaces to the 
power parameters can optionally be used for diagnostic purposes, and in 
the near future I'll propose alternative interfaces for setting entire 
operating points, but the existing cpufreq interfaces will work just 
fine regardless.

-- 
Todd

Re: PowerOP 2/3: Intel Centrino support

[Jordan Crouse]

> I've attempted to extoll the benefits of adding these interfaces in 
> previous emails, and if after that it still seems mystifying why anybody 
> would want to do this then I'll take the heat for doing a lousy job of 
> extolling.  I've also admitted that it is primarily of use in 
> embedded-specific hardware, and of less use in x86 and in desktop/server 
> usage for various reasons (unless it turns out there's some fantastic 
> savings to be had in modifying common x86 bus speeds independently of 
> cpu speed, which seems unlikely).  In the case of x86, undervolting is 
> in practice by some folks, but yes it is risky and support for it in the 
> basic interfaces probably shouldn't be a high priority.

I would like to toss in my support to Todd, if he'll take it.  When it comes
to embedded power management concepts, a consistant theme is that people
often question the usefulness, redundancy or complexity of a solution.  This
is perfectly understandable, since such a huge majority of the power
management experts and users are concentrating intently on x86 desktops and
servers.  Thats nobody's fault in particular, just a natural result of a
Wintel world gone mad.

At the PM BOF at OLS, when we started discussing runtime management, somebody
mentioned that one of the problems with RTPM is the complexity.  As an
embedded Linux developer, I hope I speak for the entire embedded community
when I say that we welcome that complexity - we are willing to do anything 
we can do to squeak every single millivolt out of our platforms.

But as a laptop owner, I can see the other side of the coin as well - I don't
know the specific voltages that my laptop uses, and I don't want to know. 

In short, we have different goals, but our hearts are in the the same place.
These same concepts are going to show up more and more in the future, and
eventually somebody is going to start shipping less then optimal solutions,
just to get something to market.  This list can either lend its expertise, or
complain when somebody else gets it wrong.  The second one might seem more
fun, but I hope we can agree its far less productive.. :)

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

Re: [linux-pm] Re: PowerOP 2/3: Intel Centrino support

[Nikolay Pelov]

On Wed, 10 Aug 2005, Dave Jones wrote:

> 
> For example, most of the x86 drivers, if you set a speed, and then
> start fiddling with the voltage, you can pretty much guarantee
> you'll crash within the next few seconds.  They have to match,
> or at the least, be within a very small margin.
> 
> Given how long its taken us to get sane userspace parts for cpufreq,
> I'm loathe to changing the interfaces yet again unless there's
> a clear advantage to doing so, as it'll take at least another 12 months
> for userspace to catch up.
> 

I'm one of those x86 folks undervolting their Pentium M laptops,
so let me share my experience/opinion. About a week after I bought my
laptop (Acer Aspire 1690, Intel Pentium M 740 at 1.7GHz), I was at the
point of returning it to the dealer because the fan was constantly on
and making too much noise even when running at 800MHz. Then I discovered
that in the windows world, folks are routinely undervolting their CPUs and
obtaining significant improvements in reduced heat and battery life.
There are a number of howto's and software tools on the topic. 
After I did the excercise myself I ended up with an almost 30% reduction
in voltage for every frequency. I didn't make measurments how much this
extends the battery life but the fan certainly spins less often.

When I wanted to do this excersise on linux I discovered that there
wasn't any support for changing voltages on centrino - only some patches
flying around on this mailing list, many of them for AMD. So, I wrote
a very simple patch myself which works as follows. Currently, there is a
table with avaliable frequencies which the cpu governors use for dynamic
frequency switching. In this table every frequency is paired with a voltage
setting so whenever someone sets a frequency, the driver also sets the
corresponding voltage. I guess that this pair is what you refer to as a
power point. The patch I wrote simply overrides the default voltages in
this pair. I may send the patch in the coming days but its just a quick
hack and not a serious solution.

To summarize, undervolting the cpu of your laptop is becoming an important
task and it would be nice to have support for it in one way or another.

Nik.

Re: PowerOP 2/3: Intel Centrino support

[Todd Poynor]

Jordan Crouse wrote:

> When it comes
> to embedded power management concepts, a consistant theme is that people
> often question the usefulness, redundancy or complexity of a solution.  This
> is perfectly understandable, since such a huge majority of the power
> management experts and users are concentrating intently on x86 desktops and
> servers.  

It also occurs to me that another reason for the disconnect between x86 
desktop/server and embedded on this point is the lack of ACPI.  We want 
to do things analogous to the power management performed by ACPI, but 
entirely in Linux, so we need to expose some of those low-level machine 
resources to our power management software.  In many cases those power 
management decisions do not revolve around the question of the MHz at 
which the CPU is to run.  Embedded Linux system power management exists 
for many of the same reasons ACPI exists.


-- 
Todd