This patch implements Barcelona CPU detection.
Signed-off-by: Robert Richter <[email protected]>
Index: linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
===================================================================
--- linux-2.6.22-rc3.orig/arch/i386/perfmon/perfmon.c
+++ linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
@@ -1059,6 +1059,7 @@ char *pfm_arch_get_pmu_module_name(void)
goto try_arch;
}
case 15:
+ case 16:
/* All Opteron processors */
if (cpu_data->x86_vendor == X86_VENDOR_AMD)
return "perfmon_k8";
Index: linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
===================================================================
--- linux-2.6.22-rc3.orig/arch/x86_64/perfmon/perfmon_k8.c
+++ linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
@@ -307,7 +307,12 @@ static int pfm_k8_probe_pmu(void)
return -1;
}
- if (current_cpu_data.x86 != 15) {
+ switch (current_cpu_data.x86) {
+ case 15:
+ case 16:
+ PFM_INFO("found family=%d", current_cpu_data.x86);
+ break;
+ default:
PFM_INFO("unsupported family=%d", current_cpu_data.x86);
return -1;
}
--
AMD Saxony, Dresden, Germany
Operating System Research Center
email: [email protected]
On Fri, 15 Jun 2007, Robert Richter wrote:
> Index: linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> ===================================================================
> --- linux-2.6.22-rc3.orig/arch/i386/perfmon/perfmon.c
> +++ linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> @@ -1059,6 +1059,7 @@ char *pfm_arch_get_pmu_module_name(void)
> goto try_arch;
> }
> case 15:
> + case 16:
> /* All Opteron processors */
> if (cpu_data->x86_vendor == X86_VENDOR_AMD)
> return "perfmon_k8";
Constants like these should be #define'd in a header file but, admittedly,
it might become a rather intrusive change at this point for the above
case.
Robert,
I applied this patch to my tree.
Thanks.
On Fri, Jun 15, 2007 at 06:57:30PM +0200, Robert Richter wrote:
> This patch implements Barcelona CPU detection.
>
> Signed-off-by: Robert Richter <[email protected]>
>
> Index: linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> ===================================================================
> --- linux-2.6.22-rc3.orig/arch/i386/perfmon/perfmon.c
> +++ linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> @@ -1059,6 +1059,7 @@ char *pfm_arch_get_pmu_module_name(void)
> goto try_arch;
> }
> case 15:
> + case 16:
> /* All Opteron processors */
> if (cpu_data->x86_vendor == X86_VENDOR_AMD)
> return "perfmon_k8";
> Index: linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> ===================================================================
> --- linux-2.6.22-rc3.orig/arch/x86_64/perfmon/perfmon_k8.c
> +++ linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> @@ -307,7 +307,12 @@ static int pfm_k8_probe_pmu(void)
> return -1;
> }
>
> - if (current_cpu_data.x86 != 15) {
> + switch (current_cpu_data.x86) {
> + case 15:
> + case 16:
> + PFM_INFO("found family=%d", current_cpu_data.x86);
> + break;
> + default:
> PFM_INFO("unsupported family=%d", current_cpu_data.x86);
> return -1;
> }
>
> --
> AMD Saxony, Dresden, Germany
> Operating System Research Center
> email: [email protected]
>
>
>
--
-Stephane
David,
thanks for your comments.
On 15.06.07 11:54:24, David Rientjes wrote:
> On Fri, 15 Jun 2007, Robert Richter wrote:
>
> > Index: linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> > ===================================================================
> > --- linux-2.6.22-rc3.orig/arch/i386/perfmon/perfmon.c
> > +++ linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> > @@ -1059,6 +1059,7 @@ char *pfm_arch_get_pmu_module_name(void)
> > goto try_arch;
> > }
> > case 15:
> > + case 16:
> > /* All Opteron processors */
> > if (cpu_data->x86_vendor == X86_VENDOR_AMD)
> > return "perfmon_k8";
>
> Constants like these should be #define'd in a header file but, admittedly,
> it might become a rather intrusive change at this point for the above
> case.
All current x86 CPU detection code in the kernel is using hard coded
numbers. Introducing new defines for family and model numbers would
not be suitable here.
Thanks,
-Robert
--
AMD Saxony, Dresden, Germany
Operating System Research Center
email: [email protected]