All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg@redhat.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"davej@redhat.com" <davej@redhat.com>,
	"Langsdorf, Mark" <mark.langsdorf@amd.com>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>
Subject: Re: [PATCH 1/5] acpi-cpufreq: Add support for modern AMD CPUs
Date: Tue, 17 May 2011 18:42:33 +0100	[thread overview]
Message-ID: <20110517174233.GA25111@srcf.ucam.org> (raw)
In-Reply-To: <20110517173536.GI30053@aftab>

On Tue, May 17, 2011 at 07:35:36PM +0200, Borislav Petkov wrote:
> On Tue, May 17, 2011 at 01:03:35PM -0400, Matthew Garrett wrote:
> > The programming model for P-states on modern AMD CPUs is very similar to
> > that of Intel and VIA. It makes sense to consolidate this support into one
> > driver rather than duplicating functionality between two of them. This
> > patch adds support for AMDs with hardware P-state control to acpi-cpufreq.
> 
> Ok, I'm a bit confused here but maybe because I don't know the whole
> cpufreq subsystem that well. Is the purpose here to add hw pstates
> support to acpi-cpufreq so that it is used on AMD but leave the old
> Fid/Vid method to powernow-k8, thus phasing it out...?

Yes. The last patch in the set removes the hw pstate code from 
powernow-k8.

> >  #define MSR_IA32_PERF_STATUS		0x00000198
> >  #define MSR_IA32_PERF_CTL		0x00000199
> > +#define MSR_AMD_PERF_STATUS		0xc0010063
> > +#define MSR_AMD_PERF_CTL		0xc0010062
> 
> Yeah, there are defines for those in
> <arch/x86/kernel/cpu/cpufreq/powernow-k8.h>:
> 
> #define MSR_PSTATE_STATUS       0xc0010063 /* Pstate Status MSR */
> #define MSR_PSTATE_CTRL         0xc0010062 /* Pstate control MSR */
> 
> can you remove them from there for consistency so that we can use only
> the msr-index.h definitions.

That happens in the final patch.

> > +static int check_powernow_cpu(unsigned int cpuid)
> > +{
> > +	struct cpuinfo_x86 *cpu = &cpu_data(cpuid);
> > +
> > +	return cpu_has(cpu, X86_FEATURE_POWERNOW);
> > +}
> 
> This could be static_cpu_has() since all the CPUs, including the boot
> CPU, will have the HwPstate thing set. Thus, you can ignore the "cpuid"
> parameter.

Ok, this was just for symmetry with the est version.

> > --- a/arch/x86/kernel/cpu/scattered.c
> > +++ b/arch/x86/kernel/cpu/scattered.c
> > @@ -39,6 +39,7 @@ void __cpuinit init_scattered_cpuid_features(struct cpuinfo_x86 *c)
> >  		{ X86_FEATURE_APERFMPERF,	CR_ECX, 0, 0x00000006, 0 },
> >  		{ X86_FEATURE_EPB,		CR_ECX, 3, 0x00000006, 0 },
> >  		{ X86_FEATURE_XSAVEOPT,		CR_EAX,	0, 0x0000000d, 1 },
> > +		{ X86_FEATURE_POWERNOW,		CR_EDX, 7, 0x80000007, 0 },
> >  		{ X86_FEATURE_CPB,		CR_EDX, 9, 0x80000007, 0 },
> >  		{ X86_FEATURE_NPT,		CR_EDX, 0, 0x8000000a, 0 },
> >  		{ X86_FEATURE_LBRV,		CR_EDX, 1, 0x8000000a, 0 },
> 
> It might make sense to split out the cpuid changes to a different patch,
> IMHO.

I'd have no problem with that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2011-05-17 17:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 17:03 [PATCH 1/5] acpi-cpufreq: Add support for modern AMD CPUs Matthew Garrett
2011-05-17 17:03 ` [PATCH 2/5] acpi-cpufreq: Add support for disabling dynamic overclocking Matthew Garrett
2011-08-02 20:21   ` Len Brown
2011-08-02 20:50     ` Borislav Petkov
2011-05-17 17:03 ` [PATCH 3/5] ACPI: Add fixups for AMD P-state figures Matthew Garrett
2011-05-17 17:03 ` [PATCH 4/5] cpufreq: Add compatibility hack to powernow-k8 Matthew Garrett
2011-05-17 17:03 ` [PATCH 5/5] cpufreq: Remove support for hardware P-state chips from powernow-k8 Matthew Garrett
2011-05-17 17:35 ` [PATCH 1/5] acpi-cpufreq: Add support for modern AMD CPUs Borislav Petkov
2011-05-17 17:42   ` Matthew Garrett [this message]
2011-05-17 18:13     ` Borislav Petkov
2011-05-17 18:17       ` Matthew Garrett
2011-05-17 18:17         ` Matthew Garrett
2011-05-19  7:26 ` Andreas Herrmann
2011-05-19  7:26   ` Andreas Herrmann
2011-08-02 20:18 ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110517174233.GA25111@srcf.ucam.org \
    --to=mjg@redhat.com \
    --cc=bp@amd64.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.