From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Ke" Subject: RE: [PATCH] 3/3 [retry 1] Add support for AMD MPERF/APERF Date: Tue, 30 Mar 2010 17:16:51 +0800 Message-ID: <33AB447FBD802F4E932063B962385B351D6D5CEB@shsmsx501.ccr.corp.intel.com> References: <201003291328.36113.mark.langsdorf@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <201003291328.36113.mark.langsdorf@amd.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Langsdorf , "xen-devel@lists.xensource.com" , "osrc-patches@elbe.amd.com" List-Id: xen-devel@lists.xenproject.org > -----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 >=20 > # 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. >=20 > 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. >=20 > This patch supersedes the patch "Add APERF/MPERF support for AMD > processors" > I sent on March 1, 2010. >=20 > Signed-off-by: Mark Langsdorf >=20 > 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 fla= g) > +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 @@ >=20 > #endif >=20 > - retval =3D drv_data[policy->cpu]->max_freq * perf_percent / 100; > + retval =3D max_freq * perf_percent / 100; >=20 > return retval; > } Changing the get_measured_perf interface definition looks not good idea. L= eaving interface unchanged and modifying the implementation is more reasona= ble to me, e.g.=20 - retval =3D drv_data[policy->cpu]->max_freq * perf_percent / 100; + retval =3D policy->cpuinfo.max_freq * perf_percent / 100; Best Regards Ke