Mark Langsdorf
2010-Mar-29 18:28 UTC
[Xen-devel] [PATCH] 3/3 [retry 1] Add support for AMD MPERF/APERF
# HG changeset patch
# User mark.langsdorf@amd.com
# Date 1269570377 18000
# Node ID 4009c47dfed487f0432b7cbe3b5bac2f805ada73
# Parent d7401eeeac32a315aa9228d012dea2e78052120d
Starting with Family 0x10, model 10 processors, some AMD processors
will have support for the APERF/MPERF MSRs. This patch adds the
checks necessary to support those MSRs.
It also makes the get_measured_perf function defined inside cpufreq.c
driver independent. The max_freq is passed to the function by the caller
instead of being taking from the acpi-cpufreq only drv_data structure.
This patch supersedes the patch "Add APERF/MPERF support for AMD
processors"
I sent on March 1, 2010.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
diff -r d7401eeeac32 -r 4009c47dfed4 xen/arch/x86/acpi/cpufreq/cpufreq.c
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c Thu Mar 25 13:02:43 2010 -0500
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c Thu Mar 25 21:26:17 2010 -0500
@@ -269,7 +269,7 @@
* Only IA32_APERF/IA32_MPERF ratio is architecturally defined and
* no meaning should be associated with absolute values of these MSRs.
*/
-static unsigned int get_measured_perf(unsigned int cpu, unsigned int flag)
+unsigned int get_measured_perf(unsigned int cpu, unsigned int flag, unsigned
int max_freq)
{
struct cpufreq_policy *policy;
struct perf_pair readin, cur, *saved;
@@ -353,7 +353,7 @@
#endif
- retval = drv_data[policy->cpu]->max_freq * perf_percent / 100;
+ retval = max_freq * perf_percent / 100;
return retval;
}
diff -r d7401eeeac32 -r 4009c47dfed4 xen/arch/x86/acpi/cpufreq/powernow.c
--- a/xen/arch/x86/acpi/cpufreq/powernow.c Thu Mar 25 13:02:43 2010 -0500
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c Thu Mar 25 21:26:17 2010 -0500
@@ -38,6 +38,7 @@
#include <acpi/acpi.h>
#include <acpi/cpufreq/cpufreq.h>
+#define CPUID_6_ECX_APERFMPERF_CAPABILITY (0x1)
#define CPUID_FREQ_VOLT_CAPABILITIES 0x80000007
#define CPB_CAPABLE 0x00000200
#define USE_HW_PSTATE 0x00000080
@@ -61,6 +62,8 @@
static struct powernow_cpufreq_data *drv_data[NR_CPUS];
+static struct cpufreq_driver powernow_cpufreq_driver;
+
struct drv_cmd {
unsigned int type;
cpumask_t mask;
@@ -249,6 +252,10 @@
if (c->cpuid_level >= 6) {
unsigned int edx;
+ unsigned int ecx;
+ ecx = cpuid_ecx(6);
+ if (ecx & CPUID_6_ECX_APERFMPERF_CAPABILITY)
+ powernow_cpufreq_driver.getavg = get_measured_perf;
edx = cpuid_edx(CPUID_FREQ_VOLT_CAPABILITIES);
if ((edx & CPB_CAPABLE) == CPB_CAPABLE) {
policy->turbo = 1;
diff -r d7401eeeac32 -r 4009c47dfed4 xen/drivers/cpufreq/utility.c
--- a/xen/drivers/cpufreq/utility.c Thu Mar 25 13:02:43 2010 -0500
+++ b/xen/drivers/cpufreq/utility.c Thu Mar 25 21:26:17 2010 -0500
@@ -382,7 +382,8 @@
if (cpufreq_driver->getavg)
{
- freq_avg = cpufreq_driver->getavg(cpu, flag);
+ freq_avg = cpufreq_driver->getavg(cpu, flag,
+ policy->cpuinfo.max_freq);
if (freq_avg > 0)
return freq_avg;
}
diff -r d7401eeeac32 -r 4009c47dfed4 xen/include/acpi/cpufreq/cpufreq.h
--- a/xen/include/acpi/cpufreq/cpufreq.h Thu Mar 25 13:02:43 2010 -0500
+++ b/xen/include/acpi/cpufreq/cpufreq.h Thu Mar 25 21:26:17 2010 -0500
@@ -138,7 +138,8 @@
unsigned int target_freq,
unsigned int relation);
unsigned int (*get)(unsigned int cpu);
- unsigned int (*getavg)(unsigned int cpu, unsigned int flag);
+ unsigned int (*getavg)(unsigned int cpu, unsigned int flag,
+ unsigned int max_freq);
int (*exit)(struct cpufreq_policy *policy);
};
diff -r d7401eeeac32 -r 4009c47dfed4 xen/include/acpi/cpufreq/processor_perf.h
--- a/xen/include/acpi/cpufreq/processor_perf.h Thu Mar 25 13:02:43 2010 -0500
+++ b/xen/include/acpi/cpufreq/processor_perf.h Thu Mar 25 21:26:17 2010 -0500
@@ -9,6 +9,8 @@
int get_cpu_id(u8);
int powernow_cpufreq_init(void);
unsigned int powernow_register_driver(void);
+unsigned int get_measured_perf(unsigned int cpu, unsigned int flag,
+ unsigned int max_freq);
void cpufreq_residency_update(unsigned int, uint8_t);
void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
-------------------------------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Yu, Ke
2010-Mar-30 09:16 UTC
RE: [Xen-devel] [PATCH] 3/3 [retry 1] Add support for AMD MPERF/APERF
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Mark Langsdorf > Sent: Tuesday, March 30, 2010 2:29 AM > To: xen-devel@lists.xensource.com; osrc-patches@elbe.amd.com > Subject: [Xen-devel] [PATCH] 3/3 [retry 1] Add support for AMD > MPERF/APERF > > # HG changeset patch > # User mark.langsdorf@amd.com > # Date 1269570377 18000 > # Node ID 4009c47dfed487f0432b7cbe3b5bac2f805ada73 > # Parent d7401eeeac32a315aa9228d012dea2e78052120d > Starting with Family 0x10, model 10 processors, some AMD processors > will have support for the APERF/MPERF MSRs. This patch adds the > checks necessary to support those MSRs. > > It also makes the get_measured_perf function defined inside cpufreq.c > driver independent. The max_freq is passed to the function by the caller > instead of being taking from the acpi-cpufreq only drv_data structure. > > This patch supersedes the patch "Add APERF/MPERF support for AMD > processors" > I sent on March 1, 2010. > > Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> > > diff -r d7401eeeac32 -r 4009c47dfed4 xen/arch/x86/acpi/cpufreq/cpufreq.c > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c Thu Mar 25 13:02:43 2010 -0500 > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c Thu Mar 25 21:26:17 > 2010 -0500 > @@ -269,7 +269,7 @@ > * Only IA32_APERF/IA32_MPERF ratio is architecturally defined and > * no meaning should be associated with absolute values of these MSRs. > */ > -static unsigned int get_measured_perf(unsigned int cpu, unsigned int flag) > +unsigned int get_measured_perf(unsigned int cpu, unsigned int flag, > unsigned > int max_freq) > { > struct cpufreq_policy *policy; > struct perf_pair readin, cur, *saved; > @@ -353,7 +353,7 @@ > > #endif > > - retval = drv_data[policy->cpu]->max_freq * perf_percent / 100; > + retval = max_freq * perf_percent / 100; > > return retval; > }Changing the get_measured_perf interface definition looks not good idea. Leaving interface unchanged and modifying the implementation is more reasonable to me, e.g. - retval = drv_data[policy->cpu]->max_freq * perf_percent / 100; + retval = policy->cpuinfo.max_freq * perf_percent / 100; Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel