From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] ACPI: Add fixups for AMD P-state figures. Date: Tue, 05 Mar 2013 15:22:25 -0500 Message-ID: <51365401.4050205@oracle.com> References: <1362512728-28770-1-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1362512728-28770-1-git-send-email-konrad.wilk@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xensource.com, bp@suse.de, stefan.bader@canonical.com List-Id: xen-devel@lists.xenproject.org On 03/05/2013 02:45 PM, Konrad Rzeszutek Wilk wrote: > This a copy-n-paste from two Linux git commits: > > - f594065faf4f9067c2283a34619fc0714e79a98d > ACPI: Add fixups for AMD P-state figures > - 9855d8ce41a7801548a05d844db2f46c3e810166 > ACPI: Check MSR valid bit before using P-state frequencies > > The issue is that "some AMD systems may round the frequencies in > ACPI tables to 100MHz boundaries. We canobtain the real > frequencies from MSRs, so add a quirk to fix these frequencies up > on AMD systems." (from f594065..) > > In discussion (around 9855d8..) "it turned out that indeed real > HW/BIOSes may choose to not set the valid bit and thus mark the > P-state as invalid. So this could be considered a fix for broken > BIOSes that also works around the issue on Xen." (from 9855d8..) > > I've tested it under Dell Inc. PowerEdge T105 /0RR825, BIOS 1.3.2 > 08/20/2008 where this quirk can indeed be observed. > > CC: stefan.bader@canonical.com > CC: bp@suse.de > CC: borislav.ostrovsky@oracle.com boris.ostrovsky@oracle.com > Signed-off-by: Konrad Rzeszutek Wilk > --- > xen/arch/x86/acpi/cpufreq/powernow.c | 38 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c > index a9b7792..0eaa16c 100644 > --- a/xen/arch/x86/acpi/cpufreq/powernow.c > +++ b/xen/arch/x86/acpi/cpufreq/powernow.c > @@ -146,7 +146,43 @@ static int powernow_cpufreq_target(struct cpufreq_policy *policy, > > return 0; > } > +#define MSR_AMD_PSTATE_DEF_BASE 0xc0010064 There is MSR_PSTATE_DEF_BASE at the top of this file which is the same thing. > +static void amd_fixup_frequency(struct xen_processor_px *px) > +{ > + u32 hi, lo, fid, did; > + int index = px->control & 0x00000007; > + > + if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) > + return; > + > + if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10) > + || boot_cpu_data.x86 == 0x11) { > + rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi); > + /* > + * MSR C001_0064+: > + * Bit 63: PstateEn. Read-write. If set, the P-state is valid. > + */ > + if (!(hi & (1UL << 31))) > + return; Identation is off. -boris > + > + fid = lo & 0x3f; > + did = (lo >> 6) & 7; > + if (boot_cpu_data.x86 == 0x10) > + px->core_frequency = (100 * (fid + 0x10)) >> did; > + else > + px->core_frequency = (100 * (fid + 8)) >> did; > + } > +} > + > +static void amd_fixup_freq(struct processor_performance *perf) > +{ > > + int i; > + > + for (i = 0; i < perf->state_count; i++) > + amd_fixup_frequency(&perf->states[i]); > + > +} > static int powernow_cpufreq_verify(struct cpufreq_policy *policy) > { > struct acpi_cpufreq_data *data; > @@ -253,6 +289,8 @@ static int powernow_cpufreq_cpu_init(struct cpufreq_policy *policy) > > policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR; > > + amd_fixup_freq(perf); > + > /* table init */ > for (i = 0; i < perf->state_count && i <= max_hw_pstate; i++) { > if (i > 0 && perf->states[i].core_frequency >=