Commit:     d7a1944e8da5e91859b98259189aaaa4d8b7fa07
Parent:     4e74663c5d7eefc1f953b9b0bdacab09917b4eac
Author:     Gary Hade <[EMAIL PROTECTED]>
AuthorDate: Mon Nov 6 15:39:23 2006 -0800
Committer:  Dave Jones <[EMAIL PROTECTED]>
CommitDate: Wed Nov 8 17:14:30 2006 -0500

    [CPUFREQ] speedstep-centrino should ignore upper performance control bits
    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.
    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.
    Signed-off-by: Gary Hade <[EMAIL PROTECTED]>
    Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 
index d2d9caf..e3fa03a 100644
--- a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
+++ b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
@@ -463,6 +463,10 @@ static int centrino_cpu_init_acpi(struct cpufreq_policy 
        for (i=0; i<p->state_count; i++) {
+               /* clear high bits (set by some BIOSes) that are non-relevant 
+                  problematic for this driver's MSR only frequency transition 
code */
+               p->states[i].control &= 0xffff;
                if (p->states[i].control != p->states[i].status) {
                        dprintk("Different control (%llu) and status values 
                                p->states[i].control, p->states[i].status);
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to