All of lore.kernel.org
 help / color / mirror / Atom feed
* Cleanups for powernow-k8
@ 2004-01-13 21:51 Pavel Machek
  2004-01-13 21:59   ` Dave Jones
  0 siblings, 1 reply; 35+ messages in thread
From: Pavel Machek @ 2004-01-13 21:51 UTC (permalink / raw)
  To: davej, cpufreq, linux, kernel list, paul.devriendt

Hi!

powernow-k8 uses strange kind of comments, and is way too
verbose. Also powernow-k7 should just shut up when it is monolithic
kernel and cpu is not k7.

[Oh and look at this:
@@ -637,6 +629,7 @@
 		}
 
 		if ((numps <= 1) || (batps <= 1)) {
+			/* FIXME: Is this right? I can see one state on battery, two states total as an usefull config */
 			printk(KERN_ERR PFX "only 1 p-state to transition\n");
 			return -ENODEV;
 		}
the test probably should be numps <= 1 only, but it does not matter as
we force numps = batps]

Please apply,
								Pavel

--- tmp/linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-01-09 20:24:13.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-01-13 21:53:29.000000000 +0100
@@ -91,18 +91,13 @@
 	struct cpuinfo_x86 *c = cpu_data;
 	unsigned int maxei, eax, ebx, ecx, edx;
 
-	if (c->x86_vendor != X86_VENDOR_AMD) {
-		printk (KERN_INFO PFX "AMD processor not detected.\n");
-		return 0;
-	}
-
-	if (c->x86 !=6) {
+	if ((c->x86_vendor != X86_VENDOR_AMD) || (c->x86 !=6)) {
+#ifdef MODULE
 		printk (KERN_INFO PFX "This module only works with AMD K7 CPUs\n");
+#endif
 		return 0;
 	}
 
-	printk (KERN_INFO PFX "AMD K7 CPU detected.\n");
-
 	if ((c->x86_model == 6) && (c->x86_mask == 0)) {
 		printk (KERN_INFO PFX "K7 660[A0] core detected, enabling errata workarounds\n");
 		have_a0 = 1;
--- tmp/linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-01-09 20:24:13.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-01-13 22:24:08.000000000 +0100
@@ -31,7 +31,7 @@
 
 #define PFX "powernow-k8: "
 #define BFX PFX "BIOS error: "
-#define VERSION "version 1.00.08 - September 26, 2003"
+#define VERSION "version 1.00.08a"
 #include "powernow-k8.h"
 
 #ifdef CONFIG_PREEMPT
@@ -107,11 +107,13 @@
 	}
 }
 
-/* Sort the fid/vid frequency table into ascending order by fid. The spec */
-/* implies that it will be sorted by BIOS, but, it only implies it, and I */
-/* prefer not to trust when I can check.                                  */
-/* Yes, it is a simple bubble sort, but the PST is really small, so the   */
-/* choice of algorithm is pretty irrelevant.                              */
+/*
+ * Sort the fid/vid frequency table into ascending order by fid. The spec
+ * implies that it will be sorted by BIOS, but, it only implies it, and I
+ * prefer not to trust when I can check.
+ * Yes, it is a simple bubble sort, but the PST is really small, so the
+ * choice of algorithm is pretty irrelevant.
+ */
 static inline void
 sort_pst(struct pst_s *ppst, u32 numpstates)
 {
@@ -134,29 +136,29 @@
 			}
 		}
 	}
-
 	return;
 }
 
-/* Return 1 if the pending bit is set. Unless we are actually just told the */
-/* processor to transition a state, seeing this bit set is really bad news. */
+/*
+ * Return 1 if the pending bit is set. Unless we are actually just told the
+ * processor to transition a state, seeing this bit set is really bad news.
+ */
 static inline int
 pending_bit_stuck(void)
 {
-	u32 lo;
-	u32 hi;
-
+	u32 lo, hi;
 	rdmsr(MSR_FIDVID_STATUS, lo, hi);
 	return lo & MSR_S_LO_CHANGE_PENDING ? 1 : 0;
 }
 
-/* Update the global current fid / vid values from the status msr. Returns 1 */
-/* on error.                                                                 */
+/*
+ * Update the global current fid / vid values from the status msr. Returns 1
+ * on error.
+ */
 static int
 query_current_values_with_pending_wait(void)
 {
-	u32 lo;
-	u32 hi;
+	u32 lo, hi;
 	u32 i = 0;
 
 	lo = MSR_S_LO_CHANGE_PENDING;
@@ -271,9 +273,11 @@
 	return 0;
 }
 
-/* Reduce the vid by the max of step or reqvid.                   */
-/* Decreasing vid codes represent increasing voltages :           */
-/* vid of 0 is 1.550V, vid of 0x1e is 0.800V, vid of 0x1f is off. */
+/*
+ * Reduce the vid by the max of step or reqvid.
+ * Decreasing vid codes represent increasing voltages:
+ * vid of 0 is 1.550V, vid of 0x1e is 0.800V, vid of 0x1f is off.
+ */
 static int
 decrease_vid_code_by_step(u32 reqvid, u32 step)
 {
@@ -316,8 +320,10 @@
 	return 0;
 }
 
-/* Phase 1 - core voltage transition ... setup appropriate voltage for the */
-/* fid transition.                                                         */
+/*
+ * Phase 1 - core voltage transition ... setup appropriate voltage for the
+ * fid transition.
+ */
 static inline int
 core_voltage_pre_transition(u32 reqvid)
 {
@@ -500,7 +506,9 @@
 	}
 
 	if (c->x86_vendor != X86_VENDOR_AMD) {
+#ifdef MODULE
 		printk(KERN_INFO PFX "Not an AMD processor\n");
+#endif
 		return 0;
 	}
 
@@ -533,9 +541,7 @@
 		return 0;
 	}
 
-	printk(KERN_INFO PFX "Found AMD Athlon 64 / Opteron processor "
-	       "supporting p-state transitions\n");
-
+	printk(KERN_INFO PFX "Found AMD processor supporting PowerNow (" VERSION ")\n");
 	return 1;
 }
 
@@ -573,33 +579,19 @@
 		}
 
 		vstable = psb->voltagestabilizationtime;
-		printk(KERN_INFO PFX "voltage stable time: %d (units 20us)\n",
-		       vstable);
-
 		dprintk(KERN_DEBUG PFX "flags2: 0x%x\n", psb->flags2);
 		rvo = psb->flags2 & 3;
 		irt = ((psb->flags2) >> 2) & 3;
 		mvs = ((psb->flags2) >> 4) & 3;
 		vidmvs = 1 << mvs;
 		batps = ((psb->flags2) >> 6) & 3;
-		printk(KERN_INFO PFX "p states on battery: %d ", batps);
-		switch (batps) {
-		case 0:
-			printk("- all available\n");
-			break;
-		case 1:
-			printk("- only the minimum\n");
-			break;
-		case 2:
-			printk("- only the 2 lowest\n");
-			break;
-		case 3:
-			printk("- only the 3 lowest\n");
-			break;
-		}
-		printk(KERN_INFO PFX "ramp voltage offset: %d\n", rvo);
-		printk(KERN_INFO PFX "isochronous relief time: %d\n", irt);
-		printk(KERN_INFO PFX "maximum voltage step: %d\n", mvs);
+
+		printk(KERN_INFO PFX "voltage stable in %d usec", vstable * 20);
+		if (batps)
+			printk(", only %d lowest states on battery", batps);
+		printk(", ramp voltage offset: %d", rvo);
+		printk(", isochronous relief time: %d", irt);
+		printk(", maximum voltage step: %d\n", mvs);
 
 		dprintk(KERN_DEBUG PFX "numpst: 0x%x\n", psb->numpst);
 		if (psb->numpst != 1) {
@@ -718,8 +711,10 @@
 	return -ENODEV;
 }
 
-/* Converts a frequency (that might not necessarily be a multiple of 200) */
-/* to a fid.                                                              */
+/*
+ * Converts a frequency (that might not necessarily be a multiple of 200)
+ * to a fid.
+ */
 static u32
 find_closest_fid(u32 freq, int searchup)
 {
@@ -985,8 +980,6 @@
 {
 	int rc;
 
-	printk(KERN_INFO PFX VERSION "\n");
-
 	if (check_supported_cpu() == 0)
 		return -ENODEV;
 

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 21:51 Cleanups for powernow-k8 Pavel Machek
@ 2004-01-13 21:59   ` Dave Jones
  0 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-13 21:59 UTC (permalink / raw)
  To: Pavel Machek; +Cc: cpufreq, linux, kernel list, paul.devriendt

On Tue, Jan 13, 2004 at 10:51:49PM +0100, Pavel Machek wrote:

 > powernow-k8 uses strange kind of comments

comments part I kinda agree with, though its not critical..

 > and is way too verbose.

I agree that something like that output belongs more in x86info,
or a standalone tool, but I think Paul wanted to keep debugging stuff
there for the time being. Maybe silence it, and have it enabled
with a 'debug' module param ? Paul ?
 
 > Also powernow-k7 should just shut up when it is monolithic
 > kernel and cpu is not k7.

Agreed, applied.

 > @@ -637,6 +629,7 @@
 >  		}
 >  
 >  		if ((numps <= 1) || (batps <= 1)) {
 > +			/* FIXME: Is this right? I can see one state on battery, two states total as an usefull config */
 >  			printk(KERN_ERR PFX "only 1 p-state to transition\n");
 >  			return -ENODEV;
 >  		}
 > the test probably should be numps <= 1 only, but it does not matter as
 > we force numps = batps]

1 state on battery sounds odd. Buggy BIOS ?

		Dave


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-13 21:59   ` Dave Jones
  0 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-13 21:59 UTC (permalink / raw)
  To: Pavel Machek; +Cc: kernel list, paul.devriendt, cpufreq, linux

On Tue, Jan 13, 2004 at 10:51:49PM +0100, Pavel Machek wrote:

 > powernow-k8 uses strange kind of comments

comments part I kinda agree with, though its not critical..

 > and is way too verbose.

I agree that something like that output belongs more in x86info,
or a standalone tool, but I think Paul wanted to keep debugging stuff
there for the time being. Maybe silence it, and have it enabled
with a 'debug' module param ? Paul ?
 
 > Also powernow-k7 should just shut up when it is monolithic
 > kernel and cpu is not k7.

Agreed, applied.

 > @@ -637,6 +629,7 @@
 >  		}
 >  
 >  		if ((numps <= 1) || (batps <= 1)) {
 > +			/* FIXME: Is this right? I can see one state on battery, two states total as an usefull config */
 >  			printk(KERN_ERR PFX "only 1 p-state to transition\n");
 >  			return -ENODEV;
 >  		}
 > the test probably should be numps <= 1 only, but it does not matter as
 > we force numps = batps]

1 state on battery sounds odd. Buggy BIOS ?

		Dave

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 21:59   ` Dave Jones
  (?)
@ 2004-01-13 23:59   ` Pavel Machek
  -1 siblings, 0 replies; 35+ messages in thread
From: Pavel Machek @ 2004-01-13 23:59 UTC (permalink / raw)
  To: Dave Jones, Pavel Machek, cpufreq, linux, kernel list, paul.devriendt

Hi!

>  > and is way too verbose.
> 
> I agree that something like that output belongs more in x86info,
> or a standalone tool, but I think Paul wanted to keep debugging stuff
> there for the time being. Maybe silence it, and have it enabled
> with a 'debug' module param ? Paul ?

I made sure all the info is still there in dmesg, just on less lines.

>  > @@ -637,6 +629,7 @@
>  >  		}
>  >  
>  >  		if ((numps <= 1) || (batps <= 1)) {
>  > +			/* FIXME: Is this right? I can see one state on battery, two states total as an usefull config */
>  >  			printk(KERN_ERR PFX "only 1 p-state to transition\n");
>  >  			return -ENODEV;
>  >  		}
>  > the test probably should be numps <= 1 only, but it does not matter as
>  > we force numps = batps]
> 
> 1 state on battery sounds odd. Buggy BIOS ?

No if you have 1 state on battery but two on AC power. That way you
*have* to be low power on battery, but can select low or high on
AC... Ugly hardware, but Intel done this before, and it kind-of makes
sense.
								Pavel

-- 
When do you have heart between your knees?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14 10:10     ` Dominik Brodowski
  (?)
@ 2004-01-14 15:21     ` Dave Jones
  -1 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-14 15:21 UTC (permalink / raw)
  To: paul.devriendt, pavel, cpufreq, linux-kernel

On Wed, Jan 14, 2004 at 11:10:41AM +0100, Dominik Brodowski wrote:
 > On Tue, Jan 13, 2004 at 11:06:05PM +0000, Dave Jones wrote:
 > > Part of the justification for cpufreq (at least on x86) was an alternative
 > > for when ACPI just doesn't work, or for when folks either don't want to,
 > > or can't run ACPI (through various other AML bugs for eg).
 > 
 > Except that the ACPI P-States implementation also uses the cpufreq
 > infrastructure.

Sure, but that came later.. 

		Dave


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14 14:49 ` paul.devriendt
@ 2004-01-14 15:08   ` Dominik Brodowski
  -1 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 15:08 UTC (permalink / raw)
  To: paul.devriendt; +Cc: pavel, davej, mark.langsdorf, cpufreq, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Wed, Jan 14, 2004 at 08:49:18AM -0600, paul.devriendt@amd.com wrote:
> Absolutely. I am planning on using them also in the new ACPI based driver,
> along with your acpi-perflib.

Excellent.

> What is your progress on getting acpi-perflib merged into the kernel so that
> an additional patch is not needed ?

Unfortunately, it seems to be too invasive in the form it was proposed at
first. However, I'm currently in the process of getting the same
infrastructure[*] in place by doing small, logical, incremental changes to
drivers/acpi/processor.c. The first three patches are submitted to Len Brown
[1][2][3]; I haven't received a reply from him about these patches yet.

What helps in developing this is that I finally own a notebook
which supports ACPI P-States....

	Dominik

[*] or almost the same infrastructure. The first two core patches assure 
that
_PPC and passive cooling work.

[1] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398569012495&w=2
[2] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398568612489&w=2
[3] http://marc.theaimsgroup.com/?l=acpi4linux&m=107407671712989&w=2

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14 15:08   ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 15:08 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, mark.langsdorf, cpufreq, pavel, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1128 bytes --]

On Wed, Jan 14, 2004 at 08:49:18AM -0600, paul.devriendt@amd.com wrote:
> Absolutely. I am planning on using them also in the new ACPI based driver,
> along with your acpi-perflib.

Excellent.

> What is your progress on getting acpi-perflib merged into the kernel so that
> an additional patch is not needed ?

Unfortunately, it seems to be too invasive in the form it was proposed at
first. However, I'm currently in the process of getting the same
infrastructure[*] in place by doing small, logical, incremental changes to
drivers/acpi/processor.c. The first three patches are submitted to Len Brown
[1][2][3]; I haven't received a reply from him about these patches yet.

What helps in developing this is that I finally own a notebook
which supports ACPI P-States....

	Dominik

[*] or almost the same infrastructure. The first two core patches assure 
that
_PPC and passive cooling work.

[1] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398569012495&w=2
[2] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398568612489&w=2
[3] http://marc.theaimsgroup.com/?l=acpi4linux&m=107407671712989&w=2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14 14:49 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14 14:49 UTC (permalink / raw)
  To: linux; +Cc: pavel, davej, mark.langsdorf, cpufreq, linux-kernel

>> hardware. Dominik sent me some great patches to use the cpufreq table support 
>> and remove some redundant code - let me know if you do not have them and
>> want me to forward them. They work great.
> 
> I've rediffed them for 2.6.1 and put them here:
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_1
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_2
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_3
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_4
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_5
> 
> Paul: do you agree to them being merged?
> 
> 	Dominik

Absolutely. I am planning on using them also in the new ACPI based driver,
along with your acpi-perflib.

What is your progress on getting acpi-perflib merged into the kernel so that
an additional patch is not needed ?

Paul.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14 14:49 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14 14:49 UTC (permalink / raw)
  To: linux; +Cc: davej, mark.langsdorf, cpufreq, pavel, linux-kernel

>> hardware. Dominik sent me some great patches to use the cpufreq table support 
>> and remove some redundant code - let me know if you do not have them and
>> want me to forward them. They work great.
> 
> I've rediffed them for 2.6.1 and put them here:
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_1
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_2
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_3
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_4
> 
> http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_5
> 
> Paul: do you agree to them being merged?
> 
> 	Dominik

Absolutely. I am planning on using them also in the new ACPI based driver,
along with your acpi-perflib.

What is your progress on getting acpi-perflib merged into the kernel so that
an additional patch is not needed ?

Paul.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  2:49 ` paul.devriendt
@ 2004-01-14 10:24   ` Dominik Brodowski
  -1 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 10:24 UTC (permalink / raw)
  To: paul.devriendt; +Cc: pavel, davej, mark.langsdorf, cpufreq, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Tue, Jan 13, 2004 at 08:49:28PM -0600, paul.devriendt@amd.com wrote:
> hardware. Dominik sent me some great patches to use the cpufreq table support 
> and remove some redundant code - let me know if you do not have them and
> want me to forward them. They work great.

I've rediffed them for 2.6.1 and put them here:

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_1

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_2

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_3

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_4

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_5

Paul: do you agree to them being merged?

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14 10:24   ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 10:24 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, mark.langsdorf, cpufreq, pavel, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 748 bytes --]

On Tue, Jan 13, 2004 at 08:49:28PM -0600, paul.devriendt@amd.com wrote:
> hardware. Dominik sent me some great patches to use the cpufreq table support 
> and remove some redundant code - let me know if you do not have them and
> want me to forward them. They work great.

I've rediffed them for 2.6.1 and put them here:

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_1

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_2

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_3

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_4

http://www.brodo.de/patches/2004_01_14/powernow-k8-2.6.1-freq_table_5

Paul: do you agree to them being merged?

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 23:06   ` Dave Jones
@ 2004-01-14 10:10     ` Dominik Brodowski
  -1 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 10:10 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, pavel, cpufreq, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

On Tue, Jan 13, 2004 at 11:06:05PM +0000, Dave Jones wrote:
> Part of the justification for cpufreq (at least on x86) was an alternative
> for when ACPI just doesn't work, or for when folks either don't want to,
> or can't run ACPI (through various other AML bugs for eg).

Except that the ACPI P-States implementation also uses the cpufreq
infrastructure.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14 10:10     ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14 10:10 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, pavel, cpufreq, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]

On Tue, Jan 13, 2004 at 11:06:05PM +0000, Dave Jones wrote:
> Part of the justification for cpufreq (at least on x86) was an alternative
> for when ACPI just doesn't work, or for when folks either don't want to,
> or can't run ACPI (through various other AML bugs for eg).

Except that the ACPI P-States implementation also uses the cpufreq
infrastructure.

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 23:06   ` Dave Jones
  (?)
@ 2004-01-14  9:33   ` Ducrot Bruno
  -1 siblings, 0 replies; 35+ messages in thread
From: Ducrot Bruno @ 2004-01-14  9:33 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, pavel, cpufreq, linux, linux-kernel

On Tue, Jan 13, 2004 at 11:06:05PM +0000, Dave Jones wrote:
> For minimal parsing of the ACPI P state tables, we shouldn't need the
> full-blown interpretor IMO.

Unfortunately, no.
Some laptop use a _INI method in order to 'write' to the _PST node..
In such laptop, the only parsing option will give you only crasp 
(see some post related to this issue on the ACPI dev list).

-- 
Ducrot Bruno

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  9:01   ` Pavel Machek
@ 2004-01-14  9:25       ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14  9:25 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Dave Jones, paul.devriendt, cpufreq, linux-kernel, mark.langsdorf

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Wed, Jan 14, 2004 at 10:01:39AM +0100, Pavel Machek wrote:
> Hi!
> 
> >  > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
> >  > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
> >  > >> I will see if I can get that to work in powernow-k8-acpi 
> >  > >  
> >  > > If done properly, that parsing code could be shared by the K7 
> >  > > driver too.
> >  > 
> >  > Agreed. Function in a header file? Don't want the drivers attempting to
> >  > call each other at runtime.
> > 
> > Works for me, or shove it out into its own .c file, and have both drivers link against it.
> 
> Would acpi parsing be usefull for non-amd systems, too?

The acpi "performance library", whether it uses the CONFIG_ACPI parser or
some small independent parser, is (at least) also useful for

- ACPI 2.0 P-States using I/O-port access [current
  arch/i386/kernel/cpu/cpufreq/acpi.c driver -- it can be cleaned up by
  that. In fact, I'm currently working on it.]

- speedstep-centrino driver [can use ACPI info instead of built-in tables]
  [sample patch based on earlier acpi-perflib patch is in the cpufreq and
   acpi-devel archives]

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  9:25       ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14  9:25 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Dave Jones, paul.devriendt, mark.langsdorf, cpufreq, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1217 bytes --]

On Wed, Jan 14, 2004 at 10:01:39AM +0100, Pavel Machek wrote:
> Hi!
> 
> >  > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
> >  > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
> >  > >> I will see if I can get that to work in powernow-k8-acpi 
> >  > >  
> >  > > If done properly, that parsing code could be shared by the K7 
> >  > > driver too.
> >  > 
> >  > Agreed. Function in a header file? Don't want the drivers attempting to
> >  > call each other at runtime.
> > 
> > Works for me, or shove it out into its own .c file, and have both drivers link against it.
> 
> Would acpi parsing be usefull for non-amd systems, too?

The acpi "performance library", whether it uses the CONFIG_ACPI parser or
some small independent parser, is (at least) also useful for

- ACPI 2.0 P-States using I/O-port access [current
  arch/i386/kernel/cpu/cpufreq/acpi.c driver -- it can be cleaned up by
  that. In fact, I'm currently working on it.]

- speedstep-centrino driver [can use ACPI info instead of built-in tables]
  [sample patch based on earlier acpi-perflib patch is in the cpufreq and
   acpi-devel archives]

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 22:37 ` paul.devriendt
@ 2004-01-14  9:17   ` Ducrot Bruno
  -1 siblings, 0 replies; 35+ messages in thread
From: Ducrot Bruno @ 2004-01-14  9:17 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, pavel, linux-kernel, cpufreq, linux

On Tue, Jan 13, 2004 at 04:37:13PM -0600, paul.devriendt@amd.com wrote:

> I have a totally new driver, that I am hoping to release within about
> a month. (I did target the end of the year, but I got distracted on
> some other stuff). The new driver :
>   - uses ACPI to figure out the available p-states. I have seen a *lot*
>     of buggy BIOSs where the PSB/PST info is wrong or missing,
>   - uses ACPI to handle battery / mains power transitions,
> and some other clean ups.

IMHO, a cpufreq driver have to not do things like that.  It's up to
a common library made eventually by ACPI folks to go.  And AFAIK
Dominik do make some patch for that.  There is not only the K8 that
can benefit from what you want to add (K7, Pentium M,...).

> I would appreciate some advice on a question ... should I leave the old
> non-ACPI capability there for those people who do not want to enable ACPI
> in the kernel ? If so, is this a big ifdef, or is there a better way to do
> it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Still IMHO, people that want to disable ACPI, but want to be able to
lower the frequency of their processor don't know what they loose.  The
ACPI C-state, for which ACPI provide a good way to save powers in the
idle loop today.  But, I have seen broken BIOS, or bug in the current
ACPI implentation, that do not permit to enable ACPI under Linux, so
unless those issues are resolved, there may be still a need to support
legacy configuration.

BTW, an other drawback for only ACPI config.  I have a K7 mobile
for which I do have only 5 P-state on the ACPI side, instead
of 9 as reported by the legacy method.  One of the P-state is
also broken (the VID is too high).  I can't say of the 'quality'
of BIOS made for the K8 architecture, but it should be possible
that you get more appropriate information via the legacy table than
the one provided by ACPI..  One solution may be a setup at kernel
boot in order to configure the powernow-k8 with legacy method even
if ACPI is enabled, or even a DMI quirk if such (broken) platform are
known.


-- 
Ducrot Bruno

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  9:17   ` Ducrot Bruno
  0 siblings, 0 replies; 35+ messages in thread
From: Ducrot Bruno @ 2004-01-14  9:17 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, linux, linux-kernel, pavel, cpufreq

On Tue, Jan 13, 2004 at 04:37:13PM -0600, paul.devriendt@amd.com wrote:

> I have a totally new driver, that I am hoping to release within about
> a month. (I did target the end of the year, but I got distracted on
> some other stuff). The new driver :
>   - uses ACPI to figure out the available p-states. I have seen a *lot*
>     of buggy BIOSs where the PSB/PST info is wrong or missing,
>   - uses ACPI to handle battery / mains power transitions,
> and some other clean ups.

IMHO, a cpufreq driver have to not do things like that.  It's up to
a common library made eventually by ACPI folks to go.  And AFAIK
Dominik do make some patch for that.  There is not only the K8 that
can benefit from what you want to add (K7, Pentium M,...).

> I would appreciate some advice on a question ... should I leave the old
> non-ACPI capability there for those people who do not want to enable ACPI
> in the kernel ? If so, is this a big ifdef, or is there a better way to do
> it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Still IMHO, people that want to disable ACPI, but want to be able to
lower the frequency of their processor don't know what they loose.  The
ACPI C-state, for which ACPI provide a good way to save powers in the
idle loop today.  But, I have seen broken BIOS, or bug in the current
ACPI implentation, that do not permit to enable ACPI under Linux, so
unless those issues are resolved, there may be still a need to support
legacy configuration.

BTW, an other drawback for only ACPI config.  I have a K7 mobile
for which I do have only 5 P-state on the ACPI side, instead
of 9 as reported by the legacy method.  One of the P-state is
also broken (the VID is too high).  I can't say of the 'quality'
of BIOS made for the K8 architecture, but it should be possible
that you get more appropriate information via the legacy table than
the one provided by ACPI..  One solution may be a setup at kernel
boot in order to configure the powernow-k8 with legacy method even
if ACPI is enabled, or even a DMI quirk if such (broken) platform are
known.


-- 
Ducrot Bruno

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  3:42   ` Dave Jones
@ 2004-01-14  9:11     ` Dominik Brodowski
  -1 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14  9:11 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, pavel, cpufreq, linux-kernel, mark.langsdorf

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Wed, Jan 14, 2004 at 03:42:37AM +0000, Dave Jones wrote:
> On Tue, Jan 13, 2004 at 09:39:53PM -0600, paul.devriendt@amd.com wrote:
>  > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
>  > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
>  > >> I will see if I can get that to work in powernow-k8-acpi 
>  > >  
>  > > If done properly, that parsing code could be shared by the K7 
>  > > driver too.
>  > 
>  > Agreed. Function in a header file? Don't want the drivers attempting to
>  > call each other at runtime.
> 
> Works for me, or shove it out into its own .c file, and have both drivers link against it.

Guys, do you remember my acpi-perflib?[1] Currently, I'm rewriting it so that
it isn't so invasive and can be merged more easily during 2.x.[2] It's exactly
what you want as base for powernow-k7-acpi and powernow-k8-acpi driver.

However, as it relies on CONFIG_ACPI, an acpi-perflib-no-acpi module which
exports the same functions, but includes a minimal parser could be added.
But let's do the easy part (CONFIG_ACPI) first.

[1] http://marc.theaimsgroup.com/?l=acpi4linux&m=106547064228222&w=2
[patches are taken down from the website, though...]

[2] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398568612489&w=2 is a
first step, another one will be sent out later today.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  9:11     ` Dominik Brodowski
  0 siblings, 0 replies; 35+ messages in thread
From: Dominik Brodowski @ 2004-01-14  9:11 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, pavel, cpufreq, linux-kernel, mark.langsdorf


[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

On Wed, Jan 14, 2004 at 03:42:37AM +0000, Dave Jones wrote:
> On Tue, Jan 13, 2004 at 09:39:53PM -0600, paul.devriendt@amd.com wrote:
>  > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
>  > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
>  > >> I will see if I can get that to work in powernow-k8-acpi 
>  > >  
>  > > If done properly, that parsing code could be shared by the K7 
>  > > driver too.
>  > 
>  > Agreed. Function in a header file? Don't want the drivers attempting to
>  > call each other at runtime.
> 
> Works for me, or shove it out into its own .c file, and have both drivers link against it.

Guys, do you remember my acpi-perflib?[1] Currently, I'm rewriting it so that
it isn't so invasive and can be merged more easily during 2.x.[2] It's exactly
what you want as base for powernow-k7-acpi and powernow-k8-acpi driver.

However, as it relies on CONFIG_ACPI, an acpi-perflib-no-acpi module which
exports the same functions, but includes a minimal parser could be added.
But let's do the easy part (CONFIG_ACPI) first.

[1] http://marc.theaimsgroup.com/?l=acpi4linux&m=106547064228222&w=2
[patches are taken down from the website, though...]

[2] http://marc.theaimsgroup.com/?l=acpi4linux&m=107398568612489&w=2 is a
first step, another one will be sent out later today.

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  3:42   ` Dave Jones
  (?)
@ 2004-01-14  9:01   ` Pavel Machek
  2004-01-14  9:25       ` Dominik Brodowski
  -1 siblings, 1 reply; 35+ messages in thread
From: Pavel Machek @ 2004-01-14  9:01 UTC (permalink / raw)
  To: Dave Jones, paul.devriendt, cpufreq, linux, linux-kernel, mark.langsdorf

Hi!

>  > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
>  > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
>  > >> I will see if I can get that to work in powernow-k8-acpi 
>  > >  
>  > > If done properly, that parsing code could be shared by the K7 
>  > > driver too.
>  > 
>  > Agreed. Function in a header file? Don't want the drivers attempting to
>  > call each other at runtime.
> 
> Works for me, or shove it out into its own .c file, and have both drivers link against it.

Would acpi parsing be usefull for non-amd systems, too?
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  3:39 ` paul.devriendt
@ 2004-01-14  3:42   ` Dave Jones
  -1 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-14  3:42 UTC (permalink / raw)
  To: paul.devriendt; +Cc: pavel, cpufreq, linux, linux-kernel, mark.langsdorf

On Tue, Jan 13, 2004 at 09:39:53PM -0600, paul.devriendt@amd.com wrote:
 > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
 > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
 > >> I will see if I can get that to work in powernow-k8-acpi 
 > >  
 > > If done properly, that parsing code could be shared by the K7 
 > > driver too.
 > 
 > Agreed. Function in a header file? Don't want the drivers attempting to
 > call each other at runtime.

Works for me, or shove it out into its own .c file, and have both drivers link against it.

		Dave


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  3:42   ` Dave Jones
  0 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-14  3:42 UTC (permalink / raw)
  To: paul.devriendt; +Cc: linux-kernel, mark.langsdorf, cpufreq, pavel, linux

On Tue, Jan 13, 2004 at 09:39:53PM -0600, paul.devriendt@amd.com wrote:
 > >> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
 > >> table of p-states from an ACPI BIOS without needing the full AML interpreter.
 > >> I will see if I can get that to work in powernow-k8-acpi 
 > >  
 > > If done properly, that parsing code could be shared by the K7 
 > > driver too.
 > 
 > Agreed. Function in a header file? Don't want the drivers attempting to
 > call each other at runtime.

Works for me, or shove it out into its own .c file, and have both drivers link against it.

		Dave

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14  3:39 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14  3:39 UTC (permalink / raw)
  To: davej; +Cc: pavel, cpufreq, linux, linux-kernel, mark.langsdorf

>> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
>> table of p-states from an ACPI BIOS without needing the full AML interpreter.
>> I will see if I can get that to work in powernow-k8-acpi 
>  
> If done properly, that parsing code could be shared by the K7 
> driver too.
> 
> 	Dave

Agreed. Function in a header file? Don't want the drivers attempting to
call each other at runtime.


 


^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14  3:39 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14  3:39 UTC (permalink / raw)
  To: davej; +Cc: linux-kernel, mark.langsdorf, cpufreq, pavel, linux

>> Dave had a good idea of a minimal ACPI parser for trying to retrieve the
>> table of p-states from an ACPI BIOS without needing the full AML interpreter.
>> I will see if I can get that to work in powernow-k8-acpi 
>  
> If done properly, that parsing code could be shared by the K7 
> driver too.
> 
> 	Dave

Agreed. Function in a header file? Don't want the drivers attempting to
call each other at runtime.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-14  2:49 ` paul.devriendt
@ 2004-01-14  3:33   ` Dave Jones
  -1 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-14  3:33 UTC (permalink / raw)
  To: paul.devriendt; +Cc: pavel, cpufreq, linux, linux-kernel, mark.langsdorf

On Tue, Jan 13, 2004 at 08:49:28PM -0600, paul.devriendt@amd.com wrote:

 > Dave had a good idea of a minimal ACPI parser for trying to retrieve the
 > table of p-states from an ACPI BIOS without needing the full AML interpreter.
 > I will see if I can get that to work in powernow-k8-acpi 
 
If done properly, that parsing code could be shared by the K7 driver too.

		Dave


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  3:33   ` Dave Jones
  0 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-14  3:33 UTC (permalink / raw)
  To: paul.devriendt; +Cc: linux-kernel, mark.langsdorf, cpufreq, pavel, linux

On Tue, Jan 13, 2004 at 08:49:28PM -0600, paul.devriendt@amd.com wrote:

 > Dave had a good idea of a minimal ACPI parser for trying to retrieve the
 > table of p-states from an ACPI BIOS without needing the full AML interpreter.
 > I will see if I can get that to work in powernow-k8-acpi 
 
If done properly, that parsing code could be shared by the K7 driver too.

		Dave

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14  2:49 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14  2:49 UTC (permalink / raw)
  To: pavel; +Cc: davej, cpufreq, linux, linux-kernel, mark.langsdorf

> I'd suggest to leave old driver there (possibly let me clean it up
> ;-)))), and create new powernow-k8-acpi, or powernow-acpi or something
> like that.
> 								Pavel

Keeping the old driver around for machines without ACPI support or with
broken ACPI support sounds reasonable to me. Please feel free to clean
it up. Feel free to send it to me if you want me to test it on additional
hardware. Dominik sent me some great patches to use the cpufreq table support 
and remove some redundant code - let me know if you do not have them and
want me to forward them. They work great.

powernow-k8-acpi sounds like a fine plan to me. Keeping the k8 in the name 
is goodness.

Dave had a good idea of a minimal ACPI parser for trying to retrieve the
table of p-states from an ACPI BIOS without needing the full AML interpreter.
I will see if I can get that to work in powernow-k8-acpi ... that way, there
is the best chance of being able to work around a broken BIOS. I hate broken
BIOSs and would rather see the BIOS vendor fix the BIOS, but that does not
always seem to happen.

Paul.


^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-14  2:49 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-14  2:49 UTC (permalink / raw)
  To: pavel; +Cc: davej, mark.langsdorf, cpufreq, linux-kernel, linux

> I'd suggest to leave old driver there (possibly let me clean it up
> ;-)))), and create new powernow-k8-acpi, or powernow-acpi or something
> like that.
> 								Pavel

Keeping the old driver around for machines without ACPI support or with
broken ACPI support sounds reasonable to me. Please feel free to clean
it up. Feel free to send it to me if you want me to test it on additional
hardware. Dominik sent me some great patches to use the cpufreq table support 
and remove some redundant code - let me know if you do not have them and
want me to forward them. They work great.

powernow-k8-acpi sounds like a fine plan to me. Keeping the k8 in the name 
is goodness.

Dave had a good idea of a minimal ACPI parser for trying to retrieve the
table of p-states from an ACPI BIOS without needing the full AML interpreter.
I will see if I can get that to work in powernow-k8-acpi ... that way, there
is the best chance of being able to work around a broken BIOS. I hate broken
BIOSs and would rather see the BIOS vendor fix the BIOS, but that does not
always seem to happen.

Paul.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 22:37 ` paul.devriendt
@ 2004-01-14  0:03   ` Pavel Machek
  -1 siblings, 0 replies; 35+ messages in thread
From: Pavel Machek @ 2004-01-14  0:03 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, pavel, cpufreq, linux, linux-kernel

Hi!

> I have a totally new driver, that I am hoping to release within about
> a month. (I did target the end of the year, but I got distracted on
> some other stuff). The new driver :
>   - uses ACPI to figure out the available p-states. I have seen a *lot*
>     of buggy BIOSs where the PSB/PST info is wrong or missing,
>   - uses ACPI to handle battery / mains power transitions,
> and some other clean ups.
> 
> I would appreciate some advice on a question ... should I leave the old
> non-ACPI capability there for those people who do not want to enable ACPI
> in the kernel ? If so, is this a big ifdef, or is there a better way to do
> it ? Or should I just say that it is dependent on ACPI, got to have
> ACPI ?

I have strange notebook here, and that one only works reasonably with
APM (with ACPI: no network IRQs, random mouse problems, random
shutdowns due to bad temperature readings).

I'd suggest to leave old driver there (possibly let me clean it up
;-)))), and create new powernow-k8-acpi, or powernow-acpi or something
like that.
								Pavel
-- 
When do you have heart between your knees?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-14  0:03   ` Pavel Machek
  0 siblings, 0 replies; 35+ messages in thread
From: Pavel Machek @ 2004-01-14  0:03 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, linux-kernel, cpufreq, pavel, linux

Hi!

> I have a totally new driver, that I am hoping to release within about
> a month. (I did target the end of the year, but I got distracted on
> some other stuff). The new driver :
>   - uses ACPI to figure out the available p-states. I have seen a *lot*
>     of buggy BIOSs where the PSB/PST info is wrong or missing,
>   - uses ACPI to handle battery / mains power transitions,
> and some other clean ups.
> 
> I would appreciate some advice on a question ... should I leave the old
> non-ACPI capability there for those people who do not want to enable ACPI
> in the kernel ? If so, is this a big ifdef, or is there a better way to do
> it ? Or should I just say that it is dependent on ACPI, got to have
> ACPI ?

I have strange notebook here, and that one only works reasonably with
APM (with ACPI: no network IRQs, random mouse problems, random
shutdowns due to bad temperature readings).

I'd suggest to leave old driver there (possibly let me clean it up
;-)))), and create new powernow-k8-acpi, or powernow-acpi or something
like that.
								Pavel
-- 
When do you have heart between your knees?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
  2004-01-13 22:37 ` paul.devriendt
@ 2004-01-13 23:06   ` Dave Jones
  -1 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-13 23:06 UTC (permalink / raw)
  To: paul.devriendt; +Cc: pavel, cpufreq, linux, linux-kernel

On Tue, Jan 13, 2004 at 04:37:13PM -0600, paul.devriendt@amd.com wrote:

 > I have a totally new driver, that I am hoping to release within about
 > a month. (I did target the end of the year, but I got distracted on
 > some other stuff). The new driver :
 >   - uses ACPI to figure out the available p-states. I have seen a *lot*
 >     of buggy BIOSs where the PSB/PST info is wrong or missing,

I've seen a ridiculous amount of broken PST's from folks running the K7 driver
too. Given the complete lack of help from some vendors[1], I think I might
add a minimal ACPI parser there too when I get time, as an alternative
source of info when the PST is obviously crap.

 > I would appreciate some advice on a question ... should I leave the old
 > non-ACPI capability there for those people who do not want to enable ACPI
 > in the kernel ? If so, is this a big ifdef, or is there a better way to do
 > it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Part of the justification for cpufreq (at least on x86) was an alternative
for when ACPI just doesn't work, or for when folks either don't want to,
or can't run ACPI (through various other AML bugs for eg).

For minimal parsing of the ACPI P state tables, we shouldn't need the
full-blown interpretor IMO.

		Dave


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Cleanups for powernow-k8
@ 2004-01-13 23:06   ` Dave Jones
  0 siblings, 0 replies; 35+ messages in thread
From: Dave Jones @ 2004-01-13 23:06 UTC (permalink / raw)
  To: paul.devriendt; +Cc: linux-kernel, cpufreq, pavel, linux

On Tue, Jan 13, 2004 at 04:37:13PM -0600, paul.devriendt@amd.com wrote:

 > I have a totally new driver, that I am hoping to release within about
 > a month. (I did target the end of the year, but I got distracted on
 > some other stuff). The new driver :
 >   - uses ACPI to figure out the available p-states. I have seen a *lot*
 >     of buggy BIOSs where the PSB/PST info is wrong or missing,

I've seen a ridiculous amount of broken PST's from folks running the K7 driver
too. Given the complete lack of help from some vendors[1], I think I might
add a minimal ACPI parser there too when I get time, as an alternative
source of info when the PST is obviously crap.

 > I would appreciate some advice on a question ... should I leave the old
 > non-ACPI capability there for those people who do not want to enable ACPI
 > in the kernel ? If so, is this a big ifdef, or is there a better way to do
 > it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Part of the justification for cpufreq (at least on x86) was an alternative
for when ACPI just doesn't work, or for when folks either don't want to,
or can't run ACPI (through various other AML bugs for eg).

For minimal parsing of the ACPI P state tables, we shouldn't need the
full-blown interpretor IMO.

		Dave

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-13 22:37 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-13 22:37 UTC (permalink / raw)
  To: davej, pavel; +Cc: cpufreq, linux, linux-kernel

> On Tue, Jan 13, 2004 at 10:51:49PM +0100, Pavel Machek wrote:
> 
>  > powernow-k8 uses strange kind of comments
> 
> comments part I kinda agree with, though its not critical..

Ok, point taken.

>  > and is way too verbose.
> 
> I agree that something like that output belongs more in x86info,
> or a standalone tool, but I think Paul wanted to keep debugging stuff
> there for the time being. Maybe silence it, and have it enabled
> with a 'debug' module param ? Paul ?

In the early days of frequency management and K8, I really wanted the
debug stuff there to help with problems in the field - the debug spew
really did help out with all of the buggy BIOSs that reported bogus
data. Things are more stable now, and it has outlived its usefulness,
it will be majorly cleaned up in the new driver (see below).

Perhaps I will put out a separate debug utility or something like that.

>  >  
>  >  		if ((numps <= 1) || (batps <= 1)) {
>  > +			/* FIXME: Is this right? I can see one 
> state on battery, two states total as an usefull config */
>  >  			printk(KERN_ERR PFX "only 1 p-state to 
> transition\n");
>  >  			return -ENODEV;
>  >  		}
>  > the test probably should be numps <= 1 only, but it does 
> not matter as
>  > we force numps = batps]
> 
> 1 state on battery sounds odd. Buggy BIOS ?

No, it can be valid. The capability was put into the spec to allow
a platform manufacturer to have a system where the battery pack
could not power the system at full speed. It is legit (only the
platform manufacturer can say whether it is correct or not) to 
say that operation must be restricted to the lowest frequency when 
mains power is not available. Add up the current draw from all the
devices including the processor, and look at the current that the
battery is capable of supplying ...

I have a totally new driver, that I am hoping to release within about
a month. (I did target the end of the year, but I got distracted on
some other stuff). The new driver :
  - uses ACPI to figure out the available p-states. I have seen a *lot*
    of buggy BIOSs where the PSB/PST info is wrong or missing,
  - uses ACPI to handle battery / mains power transitions,
and some other clean ups.

I would appreciate some advice on a question ... should I leave the old
non-ACPI capability there for those people who do not want to enable ACPI
in the kernel ? If so, is this a big ifdef, or is there a better way to do
it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Paul.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Cleanups for powernow-k8
@ 2004-01-13 22:37 ` paul.devriendt
  0 siblings, 0 replies; 35+ messages in thread
From: paul.devriendt @ 2004-01-13 22:37 UTC (permalink / raw)
  To: davej, pavel; +Cc: linux-kernel, cpufreq, linux

> On Tue, Jan 13, 2004 at 10:51:49PM +0100, Pavel Machek wrote:
> 
>  > powernow-k8 uses strange kind of comments
> 
> comments part I kinda agree with, though its not critical..

Ok, point taken.

>  > and is way too verbose.
> 
> I agree that something like that output belongs more in x86info,
> or a standalone tool, but I think Paul wanted to keep debugging stuff
> there for the time being. Maybe silence it, and have it enabled
> with a 'debug' module param ? Paul ?

In the early days of frequency management and K8, I really wanted the
debug stuff there to help with problems in the field - the debug spew
really did help out with all of the buggy BIOSs that reported bogus
data. Things are more stable now, and it has outlived its usefulness,
it will be majorly cleaned up in the new driver (see below).

Perhaps I will put out a separate debug utility or something like that.

>  >  
>  >  		if ((numps <= 1) || (batps <= 1)) {
>  > +			/* FIXME: Is this right? I can see one 
> state on battery, two states total as an usefull config */
>  >  			printk(KERN_ERR PFX "only 1 p-state to 
> transition\n");
>  >  			return -ENODEV;
>  >  		}
>  > the test probably should be numps <= 1 only, but it does 
> not matter as
>  > we force numps = batps]
> 
> 1 state on battery sounds odd. Buggy BIOS ?

No, it can be valid. The capability was put into the spec to allow
a platform manufacturer to have a system where the battery pack
could not power the system at full speed. It is legit (only the
platform manufacturer can say whether it is correct or not) to 
say that operation must be restricted to the lowest frequency when 
mains power is not available. Add up the current draw from all the
devices including the processor, and look at the current that the
battery is capable of supplying ...

I have a totally new driver, that I am hoping to release within about
a month. (I did target the end of the year, but I got distracted on
some other stuff). The new driver :
  - uses ACPI to figure out the available p-states. I have seen a *lot*
    of buggy BIOSs where the PSB/PST info is wrong or missing,
  - uses ACPI to handle battery / mains power transitions,
and some other clean ups.

I would appreciate some advice on a question ... should I leave the old
non-ACPI capability there for those people who do not want to enable ACPI
in the kernel ? If so, is this a big ifdef, or is there a better way to do
it ? Or should I just say that it is dependent on ACPI, got to have ACPI ?

Paul.

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2004-01-14 15:22 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-13 21:51 Cleanups for powernow-k8 Pavel Machek
2004-01-13 21:59 ` Dave Jones
2004-01-13 21:59   ` Dave Jones
2004-01-13 23:59   ` Pavel Machek
2004-01-13 22:37 paul.devriendt
2004-01-13 22:37 ` paul.devriendt
2004-01-13 23:06 ` Dave Jones
2004-01-13 23:06   ` Dave Jones
2004-01-14  9:33   ` Ducrot Bruno
2004-01-14 10:10   ` Dominik Brodowski
2004-01-14 10:10     ` Dominik Brodowski
2004-01-14 15:21     ` Dave Jones
2004-01-14  0:03 ` Pavel Machek
2004-01-14  0:03   ` Pavel Machek
2004-01-14  9:17 ` Ducrot Bruno
2004-01-14  9:17   ` Ducrot Bruno
2004-01-14  2:49 paul.devriendt
2004-01-14  2:49 ` paul.devriendt
2004-01-14  3:33 ` Dave Jones
2004-01-14  3:33   ` Dave Jones
2004-01-14 10:24 ` Dominik Brodowski
2004-01-14 10:24   ` Dominik Brodowski
2004-01-14  3:39 paul.devriendt
2004-01-14  3:39 ` paul.devriendt
2004-01-14  3:42 ` Dave Jones
2004-01-14  3:42   ` Dave Jones
2004-01-14  9:01   ` Pavel Machek
2004-01-14  9:25     ` Dominik Brodowski
2004-01-14  9:25       ` Dominik Brodowski
2004-01-14  9:11   ` Dominik Brodowski
2004-01-14  9:11     ` Dominik Brodowski
2004-01-14 14:49 paul.devriendt
2004-01-14 14:49 ` paul.devriendt
2004-01-14 15:08 ` Dominik Brodowski
2004-01-14 15:08   ` Dominik Brodowski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.