powernow-k8 updates

Hi!

This adds powernow-k8-acpi driver, which likes on more machines than powernow-k8, but depends on acpi. I'd like to get this into 2.6.5... Does it look okay?

Also if you have problems with your eMachines cpufreq, apply this and switch to -acpi driver. It should fix it for you.
Pavel

arch/i386/kernel/cpu/cpufreq/Kconfig +0 -0

@@ -93,6 +93,19 @@
 	depends on CPU_FREQ && EXPERIMENTAL
 	help
 	  This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors.

arch/i386/kernel/cpu/cpufreq/powernow-k8-acpi.c +4 -0

@@ -0,0 +1,987 @@
+/*
+ *   (c) 2003, 2004 Advanced Micro Devices, Inc.
+ *  Your use of this code is subject to the terms and conditions of the
+ *  GNU general public license version 2. See COPYING or

+/*
+ * Each processor may have
+ * a different number of entries in its array. I.e., processor 0 may have
+ * 3 pstates, processor 1 may have 5 pstates.
+ */

arch/i386/kernel/cpu/cpufreq/powernow-k8-acpi.c +60 -0

+static u32 query_ac(void)
+{
+	acpi_status rc;
+	unsigned long state;
+
+	if (psrh) {
+		rc = acpi_evaluate_integer(psrh, NULL, NULL, &state);
+		if (ACPI_SUCCESS(rc)) {
+			if (state == 1)
+				return POW_AC;
+			else if (state == 0)
+				return POW_BAT;
+			else
+				printk(EFX "psr state %lx\n", state);
+		}
+		else {
+			printk(EFX "error %x evaluating psr\n", rc );
+		}
+	}
+	return POW_UNK;
+}
+
+/* gives us the (optional) battery/thermal restrictions */
+static int process_ppc(acpi_handle objh)
+{
+	acpi_status rc;
+	unsigned long state;
+
+	if (objh) {
+		ppch = objh;
+	} else {
+		if (ppch) {
+			objh = ppch;
+		} else {
+			rstps = 0;
+			return 0;   
+		}
+	}
+
+	if (num_online_cpus() > 1) {
+		/* For future thermal support (next release?), rstps needs   */
+		/* to be per processor, and handled for the SMP case. Later. */
+		dprintk(EFX "ignoring attempt to restrict pstates for SMP\n");
+	}
+	else {
+		rc = acpi_evaluate_integer(objh, NULL, NULL, &state);
+		if (ACPI_SUCCESS(rc)) {
+			rstps = state & 0x0f;
+			//dprintk(DFX "pstate restrictions %x\n", rstps);
+			if (!seenrst)
+				seenrst = rstps;
+		}
+		else {
+			rstps = 0;
+			printk(EFX "error %x processing ppc\n", rc);
+			return -ENODEV;
+		}
+	}
+	return 0;
+}

Quoted 10 lines

arch/i386/kernel/cpu/cpufreq/Kconfig +4 -0

@@ -93,6 +93,19 @@
 	depends on CPU_FREQ && EXPERIMENTAL
 	help
 	  This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors.
+	  It relies on old "PST" tables. Unfortunately, many BIOSes get this table
+	  wrong. 
+
+	  For details, take a look at linux/Documentation/cpu-freq. 

arch/i386/kernel/cpu/cpufreq/Kconfig line 105

Quoted 6 lines

arch/i386/kernel/cpu/cpufreq/Kconfig +6 -0

+
+	  If in doubt, say N.
+
+config X86_POWERNOW_K8_ACPI
+	tristate "AMD Opteron/Athlon64 PowerNow! using ACPI"
+	depends on CPU_FREQ && EXPERIMENTAL

Why there is no dependency with ACPI here?

arch/i386/kernel/cpu/cpufreq/Kconfig line 110

Quoted 5 lines

arch/i386/kernel/cpu/cpufreq/Kconfig +5 -0

+/*
+ * Each processor may have
+ * a different number of entries in its array. I.e., processor 0 may have
+ * 3 pstates, processor 1 may have 5 pstates.
+ */

No. That will break current ACPI v2.0c specification. All processors shall have the same number of states. More, they have to support the same set of pairs of frequency/power consuption.

If that is not acceptable by AMD, then you have to contact ACPI SIG at <http://www.acpi.info/> in order to change specs.

For the last time, why on earth you still do not consider the ACPI perflib. Links to the cpufreq-developper mailing list with even a kind of public access have been posted. That will eliminate the following functions amongst other things. Look at drivers/acpi/processor.c

Quoted 60 lines

arch/i386/kernel/cpu/cpufreq/Kconfig +60 -0

+static u32 query_ac(void)
+{
+	acpi_status rc;
+	unsigned long state;
+
+	if (psrh) {
+		rc = acpi_evaluate_integer(psrh, NULL, NULL, &state);
+		if (ACPI_SUCCESS(rc)) {
+			if (state == 1)
+				return POW_AC;
+			else if (state == 0)
+				return POW_BAT;
+			else
+				printk(EFX "psr state %lx\n", state);
+		}
+		else {
+			printk(EFX "error %x evaluating psr\n", rc );
+		}
+	}
+	return POW_UNK;
+}
+
+/* gives us the (optional) battery/thermal restrictions */
+static int process_ppc(acpi_handle objh)
+{
+	acpi_status rc;
+	unsigned long state;
+
+	if (objh) {
+		ppch = objh;
+	} else {
+		if (ppch) {
+			objh = ppch;
+		} else {
+			rstps = 0;
+			return 0;   
+		}
+	}
+
+	if (num_online_cpus() > 1) {
+		/* For future thermal support (next release?), rstps needs   */
+		/* to be per processor, and handled for the SMP case. Later. */
+		dprintk(EFX "ignoring attempt to restrict pstates for SMP\n");
+	}
+	else {
+		rc = acpi_evaluate_integer(objh, NULL, NULL, &state);
+		if (ACPI_SUCCESS(rc)) {
+			rstps = state & 0x0f;
+			//dprintk(DFX "pstate restrictions %x\n", rstps);
+			if (!seenrst)
+				seenrst = rstps;
+		}
+		else {
+			rstps = 0;
+			printk(EFX "error %x processing ppc\n", rc);
+			return -ENODEV;
+		}
+	}
+	return 0;
+}

Quoted 2 lines

If that is not acceptable by AMD, then you have to contact ACPI SIG at <http://www.acpi.info/> in order to change specs.

Notice that amd's powernow is done through acpi, but does not comply to the acpi specs. That should be okay; in such case its up to AMD to define how it behaves.

Quoted 4 lines

For the last time, why on earth you still do not consider the ACPI perflib. Links to the cpufreq-developper mailing list with even a kind of public access have been posted. That will eliminate the following functions amongst other things. Look at drivers/acpi/processor.c

I see that file. It seems to be full of northbridge bugs workarounds, and seems to be handling processor C states. It handles powernow states on machines that do it through acpi. I do not see how I could use it, and I do not see how query_ac could disappear. It might be nice to use same processor/.../performance interface, but it is deprecated anyway.

What do I miss?

ducrot@poupon:~/kernel/linux-2.6.4-bk-acpi> grep EXPORT drivers/acpi/processor.c EXPORT_SYMBOL(acpi_processor_register_performance); EXPORT_SYMBOL(acpi_processor_unregister_performance); EXPORT_SYMBOL(acpi_processor_set_thermal_limit);

So all you need are acpi_processor_register_performance() and acpi_processor_unregister_performance(). I'm pretty sure that those functions are in 2.6.4-rc2.

If you want to play with those functions, you have to include <acpi/processor.h>, and then you have to register a driver via:
acpi_processor_register_performance(&pr, cpu) where:
- cpu is the cpu id (point-of-view of Linux, not the acpi cpu id),
- pr is a struct acpi_processor_performance (defined in acpi/processor.h).

You will have then for free:
- configurations via the acpi_processor_performance structure,
- handling of the _PPC object, so that you don't have to care about changes for that in the driver. That will be done via classic ACPI event notifications to the processor, via the limit interface writen in drivers/acpi/processor.c, and cpufreq notion of notifiers.

[Is it okay to post it to the lists for more testing and/or inclusion?]