Skip to contentSkip to conversation

Minor updates to powernow-k8

PATCH Applied Mark Langsdorf 2 participants 4 messages May 14, 2007

lore
Share & tools
lore

Mark Langsdorf

author
#0 lore raw

PATCH 1/1 Minor updates to powernow-k8

I've submitted the following patches before, but they don't seem to have made it into the tree yet.

Update the processor ID check to support newer RevF Turions and indicate number of processors and cores more cleanly in startup messages.

Signed-off-by Mark Langsdorf <[email protected]>
i386/kernel/cpu/cpufreq/powernow-k8.c renamed from i386/kernel/cpu/cpufreq/powernow-k8.c.old +2 -2
@@ -1330,8 +1330,8 @@ static int __cpuinit powernowk8_init(voi
 
 	if (supported_cpus == num_online_cpus()) {
 		printk(KERN_INFO PFX "Found %d %s "
-			"processors (" VERSION ")\n", supported_cpus,
-			boot_cpu_data.x86_model_id);
+			"processors (%d cpu cores) (" VERSION ")\n", supported_cpus/cpu_data[0].booted_cores,
+			boot_cpu_data.x86_model_id, supported_cpus);
 		return cpufreq_register_driver(&cpufreq_amd64_driver);
 	}
i386/kernel/cpu/cpufreq/powernow-k8.h renamed from i386/kernel/cpu/cpufreq/powernow-k8.h.old +1 -1
@@ -46,7 +46,7 @@ struct powernow_k8_data {
 #define CPUID_XFAM			0x0ff00000	/* extended family */
 #define CPUID_XFAM_K8			0
 #define CPUID_XMOD			0x000f0000	/* extended model */
-#define CPUID_XMOD_REV_G		0x00060000
+#define CPUID_XMOD_REV_G		0x00080000
 #define CPUID_XFAM_10H 			0x00100000	/* family 0x10 */
 #define CPUID_USE_XFAM_XMOD		0x00000f00
 #define CPUID_GET_MAX_CAPABILITIES	0x80000000
Applied
#1 lore raw
Quoted 2 lines · Mark Langsdorf

I've submitted the following patches before, but they don't seem to have made it into the tree yet.

I merged something into cpufreq.git yesterday, though not your patch, as I couldn't find it anywhere :-/

I only bumped as far as 0x70000 though which is what the user reported was necessary to make it work on his system.

Quoted 3 lines

Update the processor ID check to support newer RevF Turions and indicate number of processors and cores more cleanly in startup messages.

I'm puzzled by AMDs naming/numbering scheme.
How does RevF have a higher value than RevG ?

Also, maybe we should rename CPUID_XMOD_REV_G to CPUID_XMOD_REV_MASK or similar if it's going to continually bump and change revs ?

Dave

Signature · 1 line
http://www.codemonkey.org.uk
author
#2 lore raw
Quoted 9 lines · Mark Langsdorf
Quoted 2 lines

I've submitted the following patches before, but they don't seem to have made it into the tree yet.

I merged something into cpufreq.git yesterday, though not your patch, as I couldn't find it anywhere :-/

I only bumped as far as 0x70000 though which is what the user reported was necessary to make it work on his system.

0x80000 is the correct value.

Quoted 6 lines
Quoted 3 lines

Update the processor ID check to support newer RevF Turions and indicate number of processors and cores more cleanly in startup messages.

I'm puzzled by AMDs naming/numbering scheme.
How does RevF have a higher value than RevG ?

I'm not sure myself.

Quoted 2 lines

Also, maybe we should rename CPUID_XMOD_REV_G to CPUID_XMOD_REV_MASK or similar if it's going to continually bump and change revs ?

I suppose we could do that. Historically, we've been renaming the #define each time, but hopefully that won't be necessary any more.

-Mark Langsdorf
Operating System Research Center
AMD

#3 lore raw
Quoted 11 lines · Mark
Quoted 9 lines · Mark Langsdorf
Quoted 2 lines

I've submitted the following patches before, but they don't seem to have made it into the tree yet.

I merged something into cpufreq.git yesterday, though not your patch, as I couldn't find it anywhere :-/

I only bumped as far as 0x70000 though which is what the user reported was necessary to make it work on his system.

0x80000 is the correct value.

Ok, updated and pushed out, thanks.

Dave

Signature · 1 line
http://www.codemonkey.org.uk