Re: [PATCH] speedstep-centrino should ignore upper performance control bits

[Len Brown <len.brown@intel.com>]

On Monday 06 November 2006 21:14, Dominik Brodowski wrote:
> On Mon, Nov 06, 2006 at 03:39:23PM -0800, Gary Hade wrote:
> > 
> > On some systems such as the IBM x3650 there are bits set in the 
> > upper half of the control values provided by the _PSS object.  
> > These bits are only relevant for cpufreq drivers that use IO ports 
> > which are not currently supported by the speedstep-centrino driver.  
> ... and probably never will.
> 
> > The current MSR oriented code assumes that upper bits are not set 
> > and thus fails to work correctly when they are.  e.g. the control 
> > and status value equality check fails even though the ACPI spec 
> > allows the inequality.

> How does the acpi-cpufreq driver work with it?

acpu-cpufreq.c in Linus' tree is still IO only.
acpi-cpufreq. in Dave's tree changed to do this:
where  #define INTEL_MSR_RANGE                (0xffff)

-        cmd.addr.port = perf->control_register.address;
-        cmd.addr.bit_width = perf->control_register.bit_width;
-        cmd.val = (u32) perf->states[next_perf_state].control;
+        switch (data->cpu_feature) {
+            case SYSTEM_INTEL_MSR_CAPABLE:
+                cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
+                cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
+                msr = (u32) perf->states[next_perf_state].control & INTEL_MSR_RANGE;
+                cmd.val = (cmd.val & ~INTEL_MSR_RANGE) | msr;
+                break;
+            case SYSTEM_IO_CAPABLE:
+                cmd.type = SYSTEM_IO_CAPABLE;
+                cmd.addr.io.port = perf->control_register.address;
+                cmd.addr.io.bit_width = perf->control_register.bit_width;
+                cmd.val = (u32) perf->states[next_perf_state].control;
+                break;