Can't load speedstep-centrino on IBM x336?

Hi all,

I've been trying to get Enhanced SpeedStep working on an IBM x336 (3.6GHz Xeon). If I load the speedstep-centrino driver with cpufreq debugging turned on, I get a message about "Invalid control/status registers (1 - 1)" and the module refuses to load. It seems that the stumbling point is this chunk of code in centrino_cpu_init_acpi():

if ((p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) ||

    (p.status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)) {
        dprintk("Invalid control/status registers (%x - %x)\n",
               p.control_register.space_id, p.status_register.space_id);
        result = -EIO;
        goto err_unreg;
}

I decompiled the DSDT code that the BIOS supplies, and it seems that the _PCT method returns control and status registers in SystemIO space if \SMIM is set (it is set to 0x1 earlier):

Method (_PCT, 0, NotSerialized)

{
    If (\SMIM)
    {
        Return (Package (0x02)
        {
            ResourceTemplate ()
            {
                Register (SystemIO, 0x10, 0x00, 0x0000000000000800)
            },
            ResourceTemplate ()
            {
                Register (SystemIO, 0x10, 0x00, 0x0000000000000804)
            }
        })
    }
    Return (Package (0x02)
    {
        ResourceTemplate ()
        {
            Register (FFixedHW, 0x40, 0x00, 0x0000000000000199)
        },
        ResourceTemplate ()
        {
            Register (FFixedHW, 0x10, 0x00, 0x0000000000000198)
        }
    })
}

I checked with the ACPI specs v2.0c and v3.0, and neither of them seem to restrict the register address space to "fixed hardware". Linux, however, expects FIXED_HARDWARE, not SYSTEM_IO, causing the error space_id checking to trip. However, EST seems to work just fine on the x336 without this check. I built a kernel without this code and was able to switch frequencies and governors in a loop without any adverse effects. /proc/cpuinfo was getting updated, too.

So now I'm wondering three things: Is there a reason why there is this address space check? Can we get rid of it? And, am I supposed to be using acpi_cpufreq instead? The speedstep_centrino code seems to indicate that my CPU revision (0xF41) should be supported by this driver...

(Attached is a patch against 2.6.14-rc4 to get rid of the check.)

--Darrick

diff -Naur b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
@@ -392,14 +392,6 @@
 		goto err_unreg;
 	}
 
-	if ((p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) ||
-	    (p.status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)) {
-		dprintk("Invalid control/status registers (%x - %x)\n",
-			p.control_register.space_id, p.status_register.space_id);
-		result = -EIO;
-		goto err_unreg;
-	}
-
 	for (i=0; i<p.state_count; i++) {
 		if (p.states[i].control != p.states[i].status) {
 			dprintk("Different control (%llu) and status values (%llu)\n",

_______________________________________________
Cpufreq mailing list
[email protected]
http://lists.linux.org.uk/mailman/listinfo/cpufreq