[PATCH] Minor updates to powernow-k8

[PATCH] Minor updates to powernow-k8

[Mark Langsdorf]

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 <mark.langsdorf@amd.com>
--- arch/i386/kernel/cpu/cpufreq/powernow-k8.c.old	2007-05-14 
16:15:34.000000000 -0500
+++ arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2007-05-14 
16:16:11.000000000 -0500
@@ -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);
  	}

--- arch/i386/kernel/cpu/cpufreq/powernow-k8.h.old	2007-05-14 
16:15:44.000000000 -0500
+++ arch/i386/kernel/cpu/cpufreq/powernow-k8.h	2007-05-14 
16:16:43.000000000 -0500
@@ -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

Re: [PATCH] Minor updates to powernow-k8

[Dave Jones]

On Mon, May 14, 2007 at 04:21:37PM -0500, Mark Langsdorf wrote:
 > 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.

 > 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


-- 
http://www.codemonkey.org.uk

RE: [PATCH] Minor updates to powernow-k8

[Langsdorf, Mark]

> On Mon, May 14, 2007 at 04:21:37PM -0500, Mark Langsdorf wrote:
>  > 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.
 
>  > 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.
 
> 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

Re: [PATCH] Minor updates to powernow-k8

[Dave Jones]

On Mon, May 14, 2007 at 04:55:32PM -0500, Langsdorf, Mark wrote:
 > > On Mon, May 14, 2007 at 04:21:37PM -0500, Mark Langsdorf wrote:
 > >  > 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

-- 
http://www.codemonkey.org.uk