Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1412623 > unrolled thread

[PATCH 01/20] [v2] x86, intel: Introduce macros for Intel family numbers

Started byDave Hansen <dave@sr71.net>
First post2016-06-03 02:20 +0200
Last post2016-06-08 13:10 +0200
Articles 20 on this page of 52 — 9 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 01/20] [v2] x86, intel: Introduce macros for Intel family numbers Dave Hansen <dave@sr71.net> - 2016-06-03 02:20 +0200
    [PATCH 03/20] x86, rapl: use Intel family macros for rapl Dave Hansen <dave@sr71.net> - 2016-06-03 02:20 +0200
      [tip:perf/core] perf/x86/rapl: Use Intel family macros for RAPL tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
    [PATCH 06/20] x86, msr: add missing Intel models Dave Hansen <dave@sr71.net> - 2016-06-03 02:20 +0200
      [tip:perf/core] perf/x86/msr: Add missing Intel models tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
    [PATCH 04/20] x86, intel_idle: use Intel family macros for intel_idle Dave Hansen <dave@sr71.net> - 2016-06-03 02:20 +0200
      [tip:x86/cpu] x86/intel_idle: Use Intel family macros for  intel_idle tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 12/20] x86, edac: use Intel family name macros for edac driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
    [PATCH 14/20] x86, acpi, lss: use Intel family name macros for lpss driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86/acpi/lss: Use Intel family name macros for the  acpi_lpss driver tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 17/20] x86, mmc: use Intel family name macros for mmc driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86, mmc: Use Intel family name macros for mmc driver tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 07/20] x86, intel: use Intel model macros intead of open-coding Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86, powercap, rapl: Use Intel model macros intead of  open-coding tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 20/20] x86, powercap, rapl: add Skylake Server model number Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86, powercap, rapl: Add Skylake Server model number tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 11/20] x86, uncore: use Intel family name macros for uncore Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] perf/x86/uncore: Use Intel family name macros for  uncore tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
    [PATCH 02/20] x86, perf: use Intel family macros for core perf events Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
        Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Vince Weaver <vincent.weaver@maine.edu> - 2016-06-08 16:10 +0200
          Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Borislav Petkov <bp@alien8.de> - 2016-06-08 16:20 +0200
          Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Ingo Molnar <mingo@kernel.org> - 2016-06-08 18:30 +0200
            Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Borislav Petkov <bp@alien8.de> - 2016-06-08 18:40 +0200
              Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Stephane Eranian <eranian@google.com> - 2016-06-08 22:00 +0200
              Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Vince Weaver <vincent.weaver@maine.edu> - 2016-06-08 22:20 +0200
                Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core  perf events Borislav Petkov <bp@alien8.de> - 2016-06-08 22:50 +0200
    [PATCH 08/20] x86, rapl: reorder cpu detection table Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86, powercap, rapl: Reorder CPU detection table tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 05/20] x86, msr: use Intel family macros for msr events code Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] perf/x86/msr: Use Intel family macros for MSR  events code tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
    [PATCH 10/20] x86, cstate: use Intel Model name macros Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] perf/x86/cstate: Use Intel Model name macros tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 13:10 +0200
    [PATCH 09/20] x86, platform: use new Intel model number macros Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86/platform: Use new Intel model number macros tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 13/20] x86, cpufreq: use Intel family name macros for intel_pstate cpufreq driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86/cpufreq: Use Intel family name macros for the  intel_pstate cpufreq driver tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 16/20] x86, pmc_core: use Intel family name macros for pmc_core driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] x86/pmc_core: Use Intel family name macros for  pmc_core driver tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 19/20] x86, rapl: add Skylake server model detection Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:perf/core] perf/x86/rapl: Add Skylake server model detection tip-bot for Jacob Pan <tipbot@zytor.com> - 2016-06-08 13:10 +0200
        Re: [tip:perf/core] perf/x86/rapl: Add Skylake server model  detection Vince Weaver <vincent.weaver@maine.edu> - 2016-06-08 16:20 +0200
          Re: [tip:perf/core] perf/x86/rapl: Add Skylake server model  detection Jacob Pan <jacob.jun.pan@linux.intel.com> - 2016-06-10 14:40 +0200
            Re: [tip:perf/core] perf/x86/rapl: Add Skylake server model detection Dave Hansen <dave@sr71.net> - 2016-06-10 17:50 +0200
    [PATCH 18/20] x86, thermal: clean up and fix cpu model detection for intel_soc_dts_thermal Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86, thermal: Clean up and fix CPU model detection  for intel_soc_dts_thermal tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    [PATCH 15/20] x86, intel_telemetry: use Intel family name macros for telemetry driver Dave Hansen <dave@sr71.net> - 2016-06-03 02:30 +0200
      [tip:x86/cpu] x86/intel_telemetry: Use Intel family name macros for  telemetry driver tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 16:20 +0200
    Re: [PATCH 01/20] [v2] x86, intel: Introduce macros for Intel family numbers "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-03 02:40 +0200
    [tip:x86/urgent] x86/cpu/intel: Introduce macros for Intel family  numbers tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 12:00 +0200
    [tip:x86/urgent] x86/cpu/intel: Introduce macros for Intel family  numbers tip-bot for Dave Hansen <tipbot@zytor.com> - 2016-06-08 12:10 +0200
    Re: [PATCH 01/20] [v2] x86, intel: Introduce macros for Intel family  numbers Ingo Molnar <mingo@kernel.org> - 2016-06-08 13:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1417471 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromVince Weaver <vincent.weaver@maine.edu>
Date2016-06-08 16:10 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHMlc-1bu-11@gated-at.bofh.it>
In reply to#1417291
On Wed, 8 Jun 2016, tip-bot for Dave Hansen wrote:

> Commit-ID:  ef5f9f47d4ec4cf42bac48c7c4dafacc1b9f0630
> Gitweb:     http://git.kernel.org/tip/ef5f9f47d4ec4cf42bac48c7c4dafacc1b9f0630
> Author:     Dave Hansen <dave.hansen@linux.intel.com>
> AuthorDate: Thu, 2 Jun 2016 17:19:29 -0700
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Wed, 8 Jun 2016 12:05:58 +0200
> 
> perf/x86/intel: Use Intel family macros for core perf events
> 
> Use the new model number macros instead of spelling things out
> in the comments.

...

>  #include "../perf_event.h"
> @@ -3319,11 +3320,11 @@ static int intel_snb_pebs_broken(int cpu)
>  	u32 rev = UINT_MAX; /* default to broken for unknown models */
>  
>  	switch (cpu_data(cpu).x86_model) {
> -	case 42: /* SNB */
> +	case INTEL_FAM6_SANDYBRIDGE:


I personally find this a step backwards.

Currently it's bad enough when someone reports a problem with PAPI/perf
	"my Xeon processor isn't detected properly"

eventually you can get them to send /proc/cpuinfo so you can try to find 
out what processor they really have, and in that case you can get
the family/model numbers in plain decimal, and you can easily look up
if things are supported in the various files.

Now I then need to go look in the source, then find that it says 
INTEL_FAM6_SANDYBRIDGE and then need to take the extra step to find 
whatever header file defines these values.

Anway I doubt this will change anyone's mind but just wanted to register 
my complaint.

Vince

and don't get me started about trying to somehow match a model number to a 
code name using the AMD or intel documentation, without resorting to 
wikipedia or random tech sites.  I'm looking at you AMD fam15h model 60h.
Also "intel 6th generation i7"

[toc] | [prev] | [next] | [standalone]

#1417495 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromBorislav Petkov <bp@alien8.de>
Date2016-06-08 16:20 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHMuT-1eQ-53@gated-at.bofh.it>
In reply to#1417471
On Wed, Jun 08, 2016 at 10:09:28AM -0400, Vince Weaver wrote:
> and don't get me started about trying to somehow match a model number to a 
> code name using the AMD or intel documentation, without resorting to 
> wikipedia or random tech sites.  I'm looking at you AMD fam15h model 60h.

That's easy - Carrizo :-P

But seriously, should we do some mapping of those somewhere and then
have people look at them and point at the exact f/m/s they mean?

This issue has come up in the past too; it is one of the reasons I added
f/m/s to the boot string:

[    0.303209] AMD-Vi: Command-line override present for HPET id 0 - ignoring
[    0.389353] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.542398] smpboot: CPU0: AMD FX(tm)-8350 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0)
								    ^^^^^^^^^^^
[    0.552219] Performance Events: Fam15h core perfctr, AMD PMU driver.


-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1417646 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromIngo Molnar <mingo@kernel.org>
Date2016-06-08 18:30 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHOwF-2ud-1@gated-at.bofh.it>
In reply to#1417471
* Vince Weaver <vincent.weaver@maine.edu> wrote:

> eventually you can get them to send /proc/cpuinfo so you can try to find 
> out what processor they really have, and in that case you can get
> the family/model numbers in plain decimal, and you can easily look up
> if things are supported in the various files.

If only it was that simple! /proc/cpuinfo lists the model number in decimal, but 
half of all uses were in hexa, making grepping hard ...

So the real solution would be to print out the engineering model name in 
/proc/cpuinfo as well:

 processor       : 119
 vendor_id       : GenuineIntel
 cpu family      : 6
 model           : 62
 model name      : Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
 model string    : IvyBridge_X

... or something like that. The string could even be auto-generated from the list 
in intel-family.h?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1417669 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromBorislav Petkov <bp@alien8.de>
Date2016-06-08 18:40 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHOGm-2xG-43@gated-at.bofh.it>
In reply to#1417646
On Wed, Jun 08, 2016 at 06:25:29PM +0200, Ingo Molnar wrote:
>  model string    : IvyBridge_X
> 
> ... or something like that. The string could even be auto-generated from the list 
> in intel-family.h?

Yap, that sounds cool too. And then we should issue that too during boot:

[    0.542398] smpboot: CPU0: AMD FX(tm)-8350 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0; Piledriver)

so that we don't need to ask for dmesg *and* /proc/cpuinfo.

Hohumm, this should be very useful.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1417826 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromStephane Eranian <eranian@google.com>
Date2016-06-08 22:00 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHRNT-4rG-17@gated-at.bofh.it>
In reply to#1417669
On Wed, Jun 8, 2016 at 9:34 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Jun 08, 2016 at 06:25:29PM +0200, Ingo Molnar wrote:
>>  model string    : IvyBridge_X
>>
>> ... or something like that. The string could even be auto-generated from the list
>> in intel-family.h?
>
> Yap, that sounds cool too. And then we should issue that too during boot:
>
I like that approach too. It avoids going online to check what
micro-architecture the number maps too.
Yet, I wonder how portable that is.

> [    0.542398] smpboot: CPU0: AMD FX(tm)-8350 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0; Piledriver)
>
> so that we don't need to ask for dmesg *and* /proc/cpuinfo.
>
> Hohumm, this should be very useful.
>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1417844 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromVince Weaver <vincent.weaver@maine.edu>
Date2016-06-08 22:20 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHS7f-4Ox-9@gated-at.bofh.it>
In reply to#1417669
On Wed, 8 Jun 2016, Borislav Petkov wrote:

> On Wed, Jun 08, 2016 at 06:25:29PM +0200, Ingo Molnar wrote:
> >  model string    : IvyBridge_X
> > 
> > ... or something like that. The string could even be auto-generated from the list 
> > in intel-family.h?
> 
> Yap, that sounds cool too. And then we should issue that too during boot:
> 
> [    0.542398] smpboot: CPU0: AMD FX(tm)-8350 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0; Piledriver)
> 
> so that we don't need to ask for dmesg *and* /proc/cpuinfo.
> 
> Hohumm, this should be very useful.

However you do it, you want to make the strings match intel-family.h for 
maximum grepability.

It's also unclear what internal names matter.  For example is AMD 15h/60h
"Carrizo" or "Excavator" or both?

I just spent the afternoon making a huge RAPL/APM kernel support matrix 
for the PAPI people.

Lots of fun since
	 arch/x86/events/intel/rapl.c
and
	 drivers/powercap/intel_rapl.c

support widely different subsets of Intel hardware, and one uses decimal 
while one uses hex for the model numbers.  So I reluctantly admit unifying 
this all somehow would be nice.

(why we need two different interfaces for RAPL is another thing, not to 
mention the fact that powercap you can read the values as a normal user 
but with perf you need to be root to read the exact same thing).

Vince

[toc] | [prev] | [next] | [standalone]

#1417857 — Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

FromBorislav Petkov <bp@alien8.de>
Date2016-06-08 22:50 +0200
SubjectRe: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events
Message-ID<rHSAh-4ZD-9@gated-at.bofh.it>
In reply to#1417844
On Wed, Jun 08, 2016 at 04:15:25PM -0400, Vince Weaver wrote:
> It's also unclear what internal names matter.  For example is AMD 15h/60h
> "Carrizo" or "Excavator" or both?

Excavator is the core and Carrizo is the APU. I think of it as the
client part.

But this is exactly the problem: what name do we take? Also, sometimes
the core name is important (ISA supported) and sometimes the platform.
It depends on the feature.

Maybe a text file with more free formulations would be better.

...

> (why we need two different interfaces for RAPL is another thing, not
> to mention the fact that powercap you can read the values as a normal
> user but with perf you need to be root to read the exact same thing).

Sounds like it needs some cleaning ...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1412636 — [PATCH 08/20] x86, rapl: reorder cpu detection table

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 08/20] x86, rapl: reorder cpu detection table
Message-ID<rFL9U-4xF-35@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

Let's make an effort to group these things by microarchitecture
name.  It makes it easier to see if something got missed.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org
---

 b/drivers/powercap/intel_rapl.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff -puN drivers/powercap/intel_rapl.c~x86-intel-familites-powercap-rapl-reorder drivers/powercap/intel_rapl.c
--- a/drivers/powercap/intel_rapl.c~x86-intel-familites-powercap-rapl-reorder	2016-06-02 15:19:19.006249411 -0700
+++ b/drivers/powercap/intel_rapl.c	2016-06-02 15:19:19.011249639 -0700
@@ -1099,25 +1099,31 @@ static const struct rapl_defaults rapl_d
 static const struct x86_cpu_id rapl_ids[] __initconst = {
 	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,	rapl_defaults_byt),
+
 	RAPL_CPU(INTEL_FAM6_IVYBRIDGE,		rapl_defaults_core),
+
 	RAPL_CPU(INTEL_FAM6_HASWELL_CORE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
 	RAPL_CPU(INTEL_FAM6_HASWELL_ULT,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
+
+	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
+
+	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
+
+	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,	rapl_defaults_byt),
 	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,	rapl_defaults_cht),
 	RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD1,	rapl_defaults_tng),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD2,	rapl_defaults_ann),
 	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
+
 	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,	rapl_defaults_hsw_server),
-	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
_

[toc] | [prev] | [next] | [standalone]

#1417481 — [tip:x86/cpu] x86, powercap, rapl: Reorder CPU detection table

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 16:20 +0200
Subject[tip:x86/cpu] x86, powercap, rapl: Reorder CPU detection table
Message-ID<rHMuS-1eQ-15@gated-at.bofh.it>
In reply to#1412636
Commit-ID:  0bb04b5f2c2452fdf4e1e376421de6bb34485fbb
Gitweb:     http://git.kernel.org/tip/0bb04b5f2c2452fdf4e1e376421de6bb34485fbb
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:37 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 13:03:25 +0200

x86, powercap, rapl: Reorder CPU detection table

Let's make an effort to group these things by microarchitecture
name.  It makes it easier to see if something got missed.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: jacob.jun.pan@intel.com
Cc: linux-pm@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001937.B53A383A@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/powercap/intel_rapl.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index defa8d6..f4f8532 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1099,25 +1099,31 @@ static const struct rapl_defaults rapl_defaults_cht = {
 static const struct x86_cpu_id rapl_ids[] __initconst = {
 	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,	rapl_defaults_byt),
+
 	RAPL_CPU(INTEL_FAM6_IVYBRIDGE,		rapl_defaults_core),
+
 	RAPL_CPU(INTEL_FAM6_HASWELL_CORE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
 	RAPL_CPU(INTEL_FAM6_HASWELL_ULT,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
+
+	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
+
+	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
+	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
+
+	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,	rapl_defaults_byt),
 	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,	rapl_defaults_cht),
 	RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD1,	rapl_defaults_tng),
-	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
 	RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD2,	rapl_defaults_ann),
 	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
+
 	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,	rapl_defaults_hsw_server),
-	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
-	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, rapl_ids);

[toc] | [prev] | [next] | [standalone]

#1412637 — [PATCH 05/20] x86, msr: use Intel family macros for msr events code

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 05/20] x86, msr: use Intel family macros for msr events code
Message-ID<rFL9U-4xF-39@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

Use the new INTEL_MODEL_* macros for arch/x86/events/msr.c.

This code appears to be missing handling for "WESTMERE2" and
"SKYLAKE_X".

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
---

 b/arch/x86/events/msr.c |   59 ++++++++++++++++++++++++------------------------
 1 file changed, 30 insertions(+), 29 deletions(-)

diff -puN arch/x86/events/msr.c~x86-intel-familites-msr arch/x86/events/msr.c
--- a/arch/x86/events/msr.c~x86-intel-familites-msr	2016-06-02 15:19:17.760192698 -0700
+++ b/arch/x86/events/msr.c	2016-06-02 15:19:17.765192925 -0700
@@ -1,4 +1,5 @@
 #include <linux/perf_event.h>
+#include <asm/intel-family.h>
 
 enum perf_msr_id {
 	PERF_MSR_TSC			= 0,
@@ -34,39 +35,39 @@ static bool test_intel(int idx)
 		return false;
 
 	switch (boot_cpu_data.x86_model) {
-	case 30: /* 45nm Nehalem    */
-	case 26: /* 45nm Nehalem-EP */
-	case 46: /* 45nm Nehalem-EX */
-
-	case 37: /* 32nm Westmere    */
-	case 44: /* 32nm Westmere-EP */
-	case 47: /* 32nm Westmere-EX */
-
-	case 42: /* 32nm SandyBridge         */
-	case 45: /* 32nm SandyBridge-E/EN/EP */
-
-	case 58: /* 22nm IvyBridge       */
-	case 62: /* 22nm IvyBridge-EP/EX */
-
-	case 60: /* 22nm Haswell Core */
-	case 63: /* 22nm Haswell Server */
-	case 69: /* 22nm Haswell ULT */
-	case 70: /* 22nm Haswell + GT3e (Intel Iris Pro graphics) */
-
-	case 61: /* 14nm Broadwell Core-M */
-	case 86: /* 14nm Broadwell Xeon D */
-	case 71: /* 14nm Broadwell + GT3e (Intel Iris Pro graphics) */
-	case 79: /* 14nm Broadwell Server */
-
-	case 55: /* 22nm Atom "Silvermont"                */
-	case 77: /* 22nm Atom "Silvermont Avoton/Rangely" */
-	case 76: /* 14nm Atom "Airmont"                   */
+	case INTEL_FAM6_NEHALEM:
+	case INTEL_FAM6_NEHALEM_EP:
+	case INTEL_FAM6_NEHALEM_EX:
+
+	case INTEL_FAM6_WESTMERE:
+	case INTEL_FAM6_WESTMERE_EP:
+	case INTEL_FAM6_WESTMERE_EX:
+
+	case INTEL_FAM6_SANDYBRIDGE:
+	case INTEL_FAM6_SANDYBRIDGE_X:
+
+	case INTEL_FAM6_IVYBRIDGE:
+	case INTEL_FAM6_IVYBRIDGE_X:
+
+	case INTEL_FAM6_HASWELL_CORE:
+	case INTEL_FAM6_HASWELL_X:
+	case INTEL_FAM6_HASWELL_ULT:
+	case INTEL_FAM6_HASWELL_GT3E:
+
+	case INTEL_FAM6_BROADWELL_CORE:
+	case INTEL_FAM6_BROADWELL_XEON_D:
+	case INTEL_FAM6_BROADWELL_GT3E:
+	case INTEL_FAM6_BROADWELL_X:
+
+	case INTEL_FAM6_ATOM_SILVERMONT1:
+	case INTEL_FAM6_ATOM_SILVERMONT2:
+	case INTEL_FAM6_ATOM_AIRMONT:
 		if (idx == PERF_MSR_SMI)
 			return true;
 		break;
 
-	case 78: /* 14nm Skylake Mobile */
-	case 94: /* 14nm Skylake Desktop */
+	case INTEL_FAM6_SKYLAKE_MOBILE:
+	case INTEL_FAM6_SKYLAKE_DESKTOP:
 		if (idx == PERF_MSR_SMI || idx == PERF_MSR_PPERF)
 			return true;
 		break;
_

[toc] | [prev] | [next] | [standalone]

#1417289 — [tip:perf/core] perf/x86/msr: Use Intel family macros for MSR events code

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 13:10 +0200
Subject[tip:perf/core] perf/x86/msr: Use Intel family macros for MSR events code
Message-ID<rHJx0-7QB-23@gated-at.bofh.it>
In reply to#1412637
Commit-ID:  353bf605a771e3c86b21de017e9525aba7d64770
Gitweb:     http://git.kernel.org/tip/353bf605a771e3c86b21de017e9525aba7d64770
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:33 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 12:05:59 +0200

perf/x86/msr: Use Intel family macros for MSR events code

Use the new INTEL_MODEL_* macros for arch/x86/events/msr.c.

This code appears to be missing handling for "WESTMERE2" and
"SKYLAKE_X".

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: jacob.jun.pan@intel.com
Link: http://lkml.kernel.org/r/20160603001933.99A402B0@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/events/msr.c | 47 ++++++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
index 85ef3c2..83cf13e 100644
--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -1,4 +1,5 @@
 #include <linux/perf_event.h>
+#include <asm/intel-family.h>
 
 enum perf_msr_id {
 	PERF_MSR_TSC			= 0,
@@ -34,39 +35,39 @@ static bool test_intel(int idx)
 		return false;
 
 	switch (boot_cpu_data.x86_model) {
-	case 30: /* 45nm Nehalem    */
-	case 26: /* 45nm Nehalem-EP */
-	case 46: /* 45nm Nehalem-EX */
+	case INTEL_FAM6_NEHALEM:
+	case INTEL_FAM6_NEHALEM_EP:
+	case INTEL_FAM6_NEHALEM_EX:
 
-	case 37: /* 32nm Westmere    */
-	case 44: /* 32nm Westmere-EP */
-	case 47: /* 32nm Westmere-EX */
+	case INTEL_FAM6_WESTMERE:
+	case INTEL_FAM6_WESTMERE_EP:
+	case INTEL_FAM6_WESTMERE_EX:
 
-	case 42: /* 32nm SandyBridge         */
-	case 45: /* 32nm SandyBridge-E/EN/EP */
+	case INTEL_FAM6_SANDYBRIDGE:
+	case INTEL_FAM6_SANDYBRIDGE_X:
 
-	case 58: /* 22nm IvyBridge       */
-	case 62: /* 22nm IvyBridge-EP/EX */
+	case INTEL_FAM6_IVYBRIDGE:
+	case INTEL_FAM6_IVYBRIDGE_X:
 
-	case 60: /* 22nm Haswell Core */
-	case 63: /* 22nm Haswell Server */
-	case 69: /* 22nm Haswell ULT */
-	case 70: /* 22nm Haswell + GT3e (Intel Iris Pro graphics) */
+	case INTEL_FAM6_HASWELL_CORE:
+	case INTEL_FAM6_HASWELL_X:
+	case INTEL_FAM6_HASWELL_ULT:
+	case INTEL_FAM6_HASWELL_GT3E:
 
-	case 61: /* 14nm Broadwell Core-M */
-	case 86: /* 14nm Broadwell Xeon D */
-	case 71: /* 14nm Broadwell + GT3e (Intel Iris Pro graphics) */
-	case 79: /* 14nm Broadwell Server */
+	case INTEL_FAM6_BROADWELL_CORE:
+	case INTEL_FAM6_BROADWELL_XEON_D:
+	case INTEL_FAM6_BROADWELL_GT3E:
+	case INTEL_FAM6_BROADWELL_X:
 
-	case 55: /* 22nm Atom "Silvermont"                */
-	case 77: /* 22nm Atom "Silvermont Avoton/Rangely" */
-	case 76: /* 14nm Atom "Airmont"                   */
+	case INTEL_FAM6_ATOM_SILVERMONT1:
+	case INTEL_FAM6_ATOM_SILVERMONT2:
+	case INTEL_FAM6_ATOM_AIRMONT:
 		if (idx == PERF_MSR_SMI)
 			return true;
 		break;
 
-	case 78: /* 14nm Skylake Mobile */
-	case 94: /* 14nm Skylake Desktop */
+	case INTEL_FAM6_SKYLAKE_MOBILE:
+	case INTEL_FAM6_SKYLAKE_DESKTOP:
 		if (idx == PERF_MSR_SMI || idx == PERF_MSR_PPERF)
 			return true;
 		break;

[toc] | [prev] | [next] | [standalone]

#1412639 — [PATCH 10/20] x86, cstate: use Intel Model name macros

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 10/20] x86, cstate: use Intel Model name macros
Message-ID<rFL9U-4xF-43@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

This should be getting old by now.  Use the new macros intead of
open-coded magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kan Liang <kan.liang@intel.com>
---

 b/arch/x86/events/intel/cstate.c |   47 +++++++++++++++++++--------------------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff -puN arch/x86/events/intel/cstate.c~x86-intel-familites-cstate arch/x86/events/intel/cstate.c
--- a/arch/x86/events/intel/cstate.c~x86-intel-familites-cstate	2016-06-02 15:19:19.867288601 -0700
+++ b/arch/x86/events/intel/cstate.c	2016-06-02 15:19:19.870288738 -0700
@@ -89,6 +89,7 @@
 #include <linux/slab.h>
 #include <linux/perf_event.h>
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include "../perf_event.h"
 
 MODULE_LICENSE("GPL");
@@ -511,37 +512,37 @@ static const struct cstate_model slm_cst
 	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) &(states) }
 
 static const struct x86_cpu_id intel_cstates_match[] __initconst = {
-	X86_CSTATES_MODEL(30, nhm_cstates),    /* 45nm Nehalem              */
-	X86_CSTATES_MODEL(26, nhm_cstates),    /* 45nm Nehalem-EP           */
-	X86_CSTATES_MODEL(46, nhm_cstates),    /* 45nm Nehalem-EX           */
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM,    nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM_EP, nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM_EX, nhm_cstates),
 
-	X86_CSTATES_MODEL(37, nhm_cstates),    /* 32nm Westmere             */
-	X86_CSTATES_MODEL(44, nhm_cstates),    /* 32nm Westmere-EP          */
-	X86_CSTATES_MODEL(47, nhm_cstates),    /* 32nm Westmere-EX          */
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE,    nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE_EP, nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE_EX, nhm_cstates),
 
-	X86_CSTATES_MODEL(42, snb_cstates),    /* 32nm SandyBridge          */
-	X86_CSTATES_MODEL(45, snb_cstates),    /* 32nm SandyBridge-E/EN/EP  */
+	X86_CSTATES_MODEL(INTEL_FAM6_SANDYBRIDGE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_SANDYBRIDGE_X, snb_cstates),
 
-	X86_CSTATES_MODEL(58, snb_cstates),    /* 22nm IvyBridge            */
-	X86_CSTATES_MODEL(62, snb_cstates),    /* 22nm IvyBridge-EP/EX      */
+	X86_CSTATES_MODEL(INTEL_FAM6_IVYBRIDGE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_IVYBRIDGE_X, snb_cstates),
 
-	X86_CSTATES_MODEL(60, snb_cstates),    /* 22nm Haswell Core         */
-	X86_CSTATES_MODEL(63, snb_cstates),    /* 22nm Haswell Server       */
-	X86_CSTATES_MODEL(70, snb_cstates),    /* 22nm Haswell + GT3e       */
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_CORE, snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_X,	   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_GT3E, snb_cstates),
 
-	X86_CSTATES_MODEL(69, hswult_cstates), /* 22nm Haswell ULT          */
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_ULT, hswult_cstates),
 
-	X86_CSTATES_MODEL(55, slm_cstates),    /* 22nm Atom Silvermont      */
-	X86_CSTATES_MODEL(77, slm_cstates),    /* 22nm Atom Avoton/Rangely  */
-	X86_CSTATES_MODEL(76, slm_cstates),    /* 22nm Atom Airmont         */
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT1, slm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT2, slm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT,     slm_cstates),
 
-	X86_CSTATES_MODEL(61, snb_cstates),    /* 14nm Broadwell Core-M     */
-	X86_CSTATES_MODEL(86, snb_cstates),    /* 14nm Broadwell Xeon D     */
-	X86_CSTATES_MODEL(71, snb_cstates),    /* 14nm Broadwell + GT3e     */
-	X86_CSTATES_MODEL(79, snb_cstates),    /* 14nm Broadwell Server     */
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_CORE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_XEON_D, snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_GT3E,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_X,      snb_cstates),
 
-	X86_CSTATES_MODEL(78, snb_cstates),    /* 14nm Skylake Mobile       */
-	X86_CSTATES_MODEL(94, snb_cstates),    /* 14nm Skylake Desktop      */
+	X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_MOBILE,  snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_DESKTOP, snb_cstates),
 	{ },
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_cstates_match);
_

[toc] | [prev] | [next] | [standalone]

#1417295 — [tip:perf/core] perf/x86/cstate: Use Intel Model name macros

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 13:10 +0200
Subject[tip:perf/core] perf/x86/cstate: Use Intel Model name macros
Message-ID<rHJx0-7QB-31@gated-at.bofh.it>
In reply to#1412639
Commit-ID:  bf4ad54199333d10c212499b57f26ffeb8222c81
Gitweb:     http://git.kernel.org/tip/bf4ad54199333d10c212499b57f26ffeb8222c81
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:40 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 12:06:00 +0200

perf/x86/cstate: Use Intel Model name macros

This should be getting old by now.  Use the new macros intead of
open-coded magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: jacob.jun.pan@intel.com
Link: http://lkml.kernel.org/r/20160603001940.FE69D646@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/events/intel/cstate.c | 47 +++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index 9ba4e41..4c7638b 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -89,6 +89,7 @@
 #include <linux/slab.h>
 #include <linux/perf_event.h>
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include "../perf_event.h"
 
 MODULE_LICENSE("GPL");
@@ -511,37 +512,37 @@ static const struct cstate_model slm_cstates __initconst = {
 	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) &(states) }
 
 static const struct x86_cpu_id intel_cstates_match[] __initconst = {
-	X86_CSTATES_MODEL(30, nhm_cstates),    /* 45nm Nehalem              */
-	X86_CSTATES_MODEL(26, nhm_cstates),    /* 45nm Nehalem-EP           */
-	X86_CSTATES_MODEL(46, nhm_cstates),    /* 45nm Nehalem-EX           */
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM,    nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM_EP, nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_NEHALEM_EX, nhm_cstates),
 
-	X86_CSTATES_MODEL(37, nhm_cstates),    /* 32nm Westmere             */
-	X86_CSTATES_MODEL(44, nhm_cstates),    /* 32nm Westmere-EP          */
-	X86_CSTATES_MODEL(47, nhm_cstates),    /* 32nm Westmere-EX          */
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE,    nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE_EP, nhm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_WESTMERE_EX, nhm_cstates),
 
-	X86_CSTATES_MODEL(42, snb_cstates),    /* 32nm SandyBridge          */
-	X86_CSTATES_MODEL(45, snb_cstates),    /* 32nm SandyBridge-E/EN/EP  */
+	X86_CSTATES_MODEL(INTEL_FAM6_SANDYBRIDGE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_SANDYBRIDGE_X, snb_cstates),
 
-	X86_CSTATES_MODEL(58, snb_cstates),    /* 22nm IvyBridge            */
-	X86_CSTATES_MODEL(62, snb_cstates),    /* 22nm IvyBridge-EP/EX      */
+	X86_CSTATES_MODEL(INTEL_FAM6_IVYBRIDGE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_IVYBRIDGE_X, snb_cstates),
 
-	X86_CSTATES_MODEL(60, snb_cstates),    /* 22nm Haswell Core         */
-	X86_CSTATES_MODEL(63, snb_cstates),    /* 22nm Haswell Server       */
-	X86_CSTATES_MODEL(70, snb_cstates),    /* 22nm Haswell + GT3e       */
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_CORE, snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_X,	   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_GT3E, snb_cstates),
 
-	X86_CSTATES_MODEL(69, hswult_cstates), /* 22nm Haswell ULT          */
+	X86_CSTATES_MODEL(INTEL_FAM6_HASWELL_ULT, hswult_cstates),
 
-	X86_CSTATES_MODEL(55, slm_cstates),    /* 22nm Atom Silvermont      */
-	X86_CSTATES_MODEL(77, slm_cstates),    /* 22nm Atom Avoton/Rangely  */
-	X86_CSTATES_MODEL(76, slm_cstates),    /* 22nm Atom Airmont         */
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT1, slm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT2, slm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT,     slm_cstates),
 
-	X86_CSTATES_MODEL(61, snb_cstates),    /* 14nm Broadwell Core-M     */
-	X86_CSTATES_MODEL(86, snb_cstates),    /* 14nm Broadwell Xeon D     */
-	X86_CSTATES_MODEL(71, snb_cstates),    /* 14nm Broadwell + GT3e     */
-	X86_CSTATES_MODEL(79, snb_cstates),    /* 14nm Broadwell Server     */
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_CORE,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_XEON_D, snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_GT3E,   snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_X,      snb_cstates),
 
-	X86_CSTATES_MODEL(78, snb_cstates),    /* 14nm Skylake Mobile       */
-	X86_CSTATES_MODEL(94, snb_cstates),    /* 14nm Skylake Desktop      */
+	X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_MOBILE,  snb_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_DESKTOP, snb_cstates),
 	{ },
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_cstates_match);

[toc] | [prev] | [next] | [standalone]

#1412640 — [PATCH 09/20] x86, platform: use new Intel model number macros

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 09/20] x86, platform: use new Intel model number macros
Message-ID<rFL9V-4xF-57@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

Remove the open-coded model numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---

 b/arch/x86/include/asm/intel-family.h       |    4 ++--
 b/arch/x86/platform/atom/punit_atom_debug.c |    5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff -puN arch/x86/include/asm/intel-family.h~x86-intel-familites-punit arch/x86/include/asm/intel-family.h
--- a/arch/x86/include/asm/intel-family.h~x86-intel-familites-punit	2016-06-02 17:10:30.027247326 -0700
+++ b/arch/x86/include/asm/intel-family.h	2016-06-02 17:10:49.390122378 -0700
@@ -53,9 +53,9 @@
 #define INTEL_FAM6_ATOM_PENWELL		0x27
 #define INTEL_FAM6_ATOM_CLOVERVIEW	0x35
 #define INTEL_FAM6_ATOM_CEDARVIEW	0x36
-#define INTEL_FAM6_ATOM_SILVERMONT1	0x37 /* BayTrail/BYT */
+#define INTEL_FAM6_ATOM_SILVERMONT1	0x37 /* BayTrail/BYT / Valleyview */
 #define INTEL_FAM6_ATOM_SILVERMONT2	0x4D /* Avaton/Rangely */
-#define INTEL_FAM6_ATOM_AIRMONT		0x4C /* CherryTrail */
+#define INTEL_FAM6_ATOM_AIRMONT		0x4C /* CherryTrail / Braswell */
 #define INTEL_FAM6_ATOM_MERRIFIELD1	0x4A /* Tangier */
 #define INTEL_FAM6_ATOM_MERRIFIELD2	0x5A /* Annidale */
 #define INTEL_FAM6_ATOM_GOLDMONT	0x5C
diff -puN arch/x86/platform/atom/punit_atom_debug.c~x86-intel-familites-punit arch/x86/platform/atom/punit_atom_debug.c
--- a/arch/x86/platform/atom/punit_atom_debug.c~x86-intel-familites-punit	2016-06-02 17:10:30.029247416 -0700
+++ b/arch/x86/platform/atom/punit_atom_debug.c	2016-06-02 17:10:30.034247642 -0700
@@ -23,6 +23,7 @@
 #include <linux/seq_file.h>
 #include <linux/io.h>
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include <asm/iosf_mbi.h>
 
 /* Power gate status reg */
@@ -143,8 +144,8 @@ static void punit_dbgfs_unregister(void)
 	  (kernel_ulong_t)&drv_data }
 
 static const struct x86_cpu_id intel_punit_cpu_ids[] = {
-	ICPU(55, punit_device_byt), /* Valleyview, Bay Trail */
-	ICPU(76, punit_device_cht), /* Braswell, Cherry Trail */
+	ICPU(INTEL_FAM6_ATOM_SILVERMONT1, punit_device_byt),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT,	  punit_device_cht),
 	{}
 };
 
_

[toc] | [prev] | [next] | [standalone]

#1417482 — [tip:x86/cpu] x86/platform: Use new Intel model number macros

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 16:20 +0200
Subject[tip:x86/cpu] x86/platform: Use new Intel model number macros
Message-ID<rHMuS-1eQ-13@gated-at.bofh.it>
In reply to#1412640
Commit-ID:  d5e0c89a8ccde900c3245474915ea0f518abdb79
Gitweb:     http://git.kernel.org/tip/d5e0c89a8ccde900c3245474915ea0f518abdb79
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:39 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 13:03:25 +0200

x86/platform: Use new Intel model number macros

Remove the open-coded model numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: jacob.jun.pan@intel.com
Link: http://lkml.kernel.org/r/20160603001939.D1D7FC2F@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/platform/atom/punit_atom_debug.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/atom/punit_atom_debug.c b/arch/x86/platform/atom/punit_atom_debug.c
index 81c769e..1097829 100644
--- a/arch/x86/platform/atom/punit_atom_debug.c
+++ b/arch/x86/platform/atom/punit_atom_debug.c
@@ -23,6 +23,7 @@
 #include <linux/seq_file.h>
 #include <linux/io.h>
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include <asm/iosf_mbi.h>
 
 /* Power gate status reg */
@@ -143,8 +144,8 @@ static void punit_dbgfs_unregister(void)
 	  (kernel_ulong_t)&drv_data }
 
 static const struct x86_cpu_id intel_punit_cpu_ids[] = {
-	ICPU(55, punit_device_byt), /* Valleyview, Bay Trail */
-	ICPU(76, punit_device_cht), /* Braswell, Cherry Trail */
+	ICPU(INTEL_FAM6_ATOM_SILVERMONT1, punit_device_byt),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT,	  punit_device_cht),
 	{}
 };

[toc] | [prev] | [next] | [standalone]

#1412641 — [PATCH 13/20] x86, cpufreq: use Intel family name macros for intel_pstate cpufreq driver

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 13/20] x86, cpufreq: use Intel family name macros for intel_pstate cpufreq driver
Message-ID<rFL9U-4xF-45@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

Another straightforward replacement of magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org
---

 b/drivers/cpufreq/intel_pstate.c |   37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff -puN drivers/cpufreq/intel_pstate.c~x86-intel-families-cpufreq-pstate drivers/cpufreq/intel_pstate.c
--- a/drivers/cpufreq/intel_pstate.c~x86-intel-families-cpufreq-pstate	2016-06-02 15:19:21.152347090 -0700
+++ b/drivers/cpufreq/intel_pstate.c	2016-06-02 15:19:21.157347317 -0700
@@ -35,6 +35,7 @@
 #include <asm/msr.h>
 #include <asm/cpu_device_id.h>
 #include <asm/cpufeature.h>
+#include <asm/intel-family.h>
 
 #define ATOM_RATIOS		0x66a
 #define ATOM_VIDS		0x66b
@@ -1352,29 +1353,29 @@ static void intel_pstate_update_util(str
 			(unsigned long)&policy }
 
 static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
-	ICPU(0x2a, core_params),
-	ICPU(0x2d, core_params),
-	ICPU(0x37, silvermont_params),
-	ICPU(0x3a, core_params),
-	ICPU(0x3c, core_params),
-	ICPU(0x3d, core_params),
-	ICPU(0x3e, core_params),
-	ICPU(0x3f, core_params),
-	ICPU(0x45, core_params),
-	ICPU(0x46, core_params),
-	ICPU(0x47, core_params),
-	ICPU(0x4c, airmont_params),
-	ICPU(0x4e, core_params),
-	ICPU(0x4f, core_params),
-	ICPU(0x5e, core_params),
-	ICPU(0x56, core_params),
-	ICPU(0x57, knl_params),
+	ICPU(INTEL_FAM6_SANDYBRIDGE, 		core_params),
+	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		core_params),
+	ICPU(INTEL_FAM6_ATOM_SILVERMONT1,	silvermont_params),
+	ICPU(INTEL_FAM6_IVYBRIDGE,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_CORE,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_CORE,		core_params),
+	ICPU(INTEL_FAM6_IVYBRIDGE_X,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_X,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_ULT,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_GT3E,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_GT3E,		core_params),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT,		airmont_params),
+	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_X,		core_params),
+	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	core_params),
+	ICPU(INTEL_FAM6_BROADWELL_XEON_D,	core_params),
+	ICPU(INTEL_FAM6_XEON_PHI_KNL,		knl_params),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
 
 static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] = {
-	ICPU(0x56, core_params),
+	ICPU(INTEL_FAM6_BROADWELL_XEON_D, core_params),
 	{}
 };
 
_

[toc] | [prev] | [next] | [standalone]

#1417489 — [tip:x86/cpu] x86/cpufreq: Use Intel family name macros for the intel_pstate cpufreq driver

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 16:20 +0200
Subject[tip:x86/cpu] x86/cpufreq: Use Intel family name macros for the intel_pstate cpufreq driver
Message-ID<rHMuS-1eQ-25@gated-at.bofh.it>
In reply to#1412641
Commit-ID:  5b20c944882ce35da0074b9eabe41a172aea030b
Gitweb:     http://git.kernel.org/tip/5b20c944882ce35da0074b9eabe41a172aea030b
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:45 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 13:03:26 +0200

x86/cpufreq: Use Intel family name macros for the intel_pstate cpufreq driver

Another straightforward replacement of magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: jacob.jun.pan@intel.com
Cc: linux-pm@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001945.0F5D02AA@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/cpufreq/intel_pstate.c | 37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 0d159b5..9b1f5d7 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -35,6 +35,7 @@
 #include <asm/msr.h>
 #include <asm/cpu_device_id.h>
 #include <asm/cpufeature.h>
+#include <asm/intel-family.h>
 
 #define ATOM_RATIOS		0x66a
 #define ATOM_VIDS		0x66b
@@ -1352,29 +1353,29 @@ static void intel_pstate_update_util(struct update_util_data *data, u64 time,
 			(unsigned long)&policy }
 
 static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
-	ICPU(0x2a, core_params),
-	ICPU(0x2d, core_params),
-	ICPU(0x37, silvermont_params),
-	ICPU(0x3a, core_params),
-	ICPU(0x3c, core_params),
-	ICPU(0x3d, core_params),
-	ICPU(0x3e, core_params),
-	ICPU(0x3f, core_params),
-	ICPU(0x45, core_params),
-	ICPU(0x46, core_params),
-	ICPU(0x47, core_params),
-	ICPU(0x4c, airmont_params),
-	ICPU(0x4e, core_params),
-	ICPU(0x4f, core_params),
-	ICPU(0x5e, core_params),
-	ICPU(0x56, core_params),
-	ICPU(0x57, knl_params),
+	ICPU(INTEL_FAM6_SANDYBRIDGE, 		core_params),
+	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		core_params),
+	ICPU(INTEL_FAM6_ATOM_SILVERMONT1,	silvermont_params),
+	ICPU(INTEL_FAM6_IVYBRIDGE,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_CORE,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_CORE,		core_params),
+	ICPU(INTEL_FAM6_IVYBRIDGE_X,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_X,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_ULT,		core_params),
+	ICPU(INTEL_FAM6_HASWELL_GT3E,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_GT3E,		core_params),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT,		airmont_params),
+	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		core_params),
+	ICPU(INTEL_FAM6_BROADWELL_X,		core_params),
+	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	core_params),
+	ICPU(INTEL_FAM6_BROADWELL_XEON_D,	core_params),
+	ICPU(INTEL_FAM6_XEON_PHI_KNL,		knl_params),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
 
 static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] = {
-	ICPU(0x56, core_params),
+	ICPU(INTEL_FAM6_BROADWELL_XEON_D, core_params),
 	{}
 };

[toc] | [prev] | [next] | [standalone]

#1412642 — [PATCH 16/20] x86, pmc_core: use Intel family name macros for pmc_core driver

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 16/20] x86, pmc_core: use Intel family name macros for pmc_core driver
Message-ID<rFL9U-4xF-49@gated-at.bofh.it>
In reply to#1412623
From: Dave Hansen <dave.hansen@linux.intel.com>

Another straightforward replacement of magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Darren Hart <dvhart@infradead.org>
Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com>
Cc: platform-driver-x86@vger.kernel.org
---

 b/drivers/platform/x86/intel_pmc_core.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff -puN drivers/platform/x86/intel_pmc_core.c~x86-intel-families-pmc_core drivers/platform/x86/intel_pmc_core.c
--- a/drivers/platform/x86/intel_pmc_core.c~x86-intel-families-pmc_core	2016-06-02 15:19:22.437405579 -0700
+++ b/drivers/platform/x86/intel_pmc_core.c	2016-06-02 15:19:22.440405715 -0700
@@ -26,6 +26,7 @@
 #include <linux/seq_file.h>
 
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include <asm/pmc_core.h>
 
 #include "intel_pmc_core.h"
@@ -138,10 +139,10 @@ static inline void pmc_core_dbgfs_unregi
 #endif /* CONFIG_DEBUG_FS */
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
-	{ X86_VENDOR_INTEL, 6, 0x4e, X86_FEATURE_MWAIT,
-		(kernel_ulong_t)NULL}, /* Skylake CPUID Signature */
-	{ X86_VENDOR_INTEL, 6, 0x5e, X86_FEATURE_MWAIT,
-		(kernel_ulong_t)NULL}, /* Skylake CPUID Signature */
+	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_MOBILE, X86_FEATURE_MWAIT,
+		(kernel_ulong_t)NULL},
+	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_DESKTOP, X86_FEATURE_MWAIT,
+		(kernel_ulong_t)NULL},
 	{}
 };
 
_

[toc] | [prev] | [next] | [standalone]

#1417491 — [tip:perf/core] x86/pmc_core: Use Intel family name macros for pmc_core driver

Fromtip-bot for Dave Hansen <tipbot@zytor.com>
Date2016-06-08 16:20 +0200
Subject[tip:perf/core] x86/pmc_core: Use Intel family name macros for pmc_core driver
Message-ID<rHMuS-1eQ-31@gated-at.bofh.it>
In reply to#1412642
Commit-ID:  70e0d117f2502f19517be03a64b3c513f31b3cdb
Gitweb:     http://git.kernel.org/tip/70e0d117f2502f19517be03a64b3c513f31b3cdb
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Thu, 2 Jun 2016 17:19:49 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 8 Jun 2016 13:02:52 +0200

x86/pmc_core: Use Intel family name macros for pmc_core driver

Another straightforward replacement of magic numbers.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Darren Hart <dvhart@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com>
Cc: jacob.jun.pan@intel.com
Cc: platform-driver-x86@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001949.7D5B9534@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/platform/x86/intel_pmc_core.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 2776bec..e57f923 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -26,6 +26,7 @@
 #include <linux/seq_file.h>
 
 #include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
 #include <asm/pmc_core.h>
 
 #include "intel_pmc_core.h"
@@ -138,10 +139,10 @@ static inline void pmc_core_dbgfs_unregister(struct pmc_dev *pmcdev)
 #endif /* CONFIG_DEBUG_FS */
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
-	{ X86_VENDOR_INTEL, 6, 0x4e, X86_FEATURE_MWAIT,
-		(kernel_ulong_t)NULL}, /* Skylake CPUID Signature */
-	{ X86_VENDOR_INTEL, 6, 0x5e, X86_FEATURE_MWAIT,
-		(kernel_ulong_t)NULL}, /* Skylake CPUID Signature */
+	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_MOBILE, X86_FEATURE_MWAIT,
+		(kernel_ulong_t)NULL},
+	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_DESKTOP, X86_FEATURE_MWAIT,
+		(kernel_ulong_t)NULL},
 	{}
 };

[toc] | [prev] | [next] | [standalone]

#1412643 — [PATCH 19/20] x86, rapl: add Skylake server model detection

FromDave Hansen <dave@sr71.net>
Date2016-06-03 02:30 +0200
Subject[PATCH 19/20] x86, rapl: add Skylake server model detection
Message-ID<rFL9U-4xF-47@gated-at.bofh.it>
In reply to#1412623
From: Jacob Pan <jacob.jun.pan@linux.intel.com>

SKX uses similar RAPL interface as Broadwell server.

Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---

 b/arch/x86/events/intel/rapl.c |    1 +
 1 file changed, 1 insertion(+)

diff -puN arch/x86/events/intel/rapl.c~x86-intel-familites-rapl-skx arch/x86/events/intel/rapl.c
--- a/arch/x86/events/intel/rapl.c~x86-intel-familites-rapl-skx	2016-06-02 15:19:23.679462110 -0700
+++ b/arch/x86/events/intel/rapl.c	2016-06-02 15:19:23.688462520 -0700
@@ -807,6 +807,7 @@ static const struct x86_cpu_id rapl_cpu_
 
 	X86_RAPL_MODEL_MATCH(INTEL_FAM6_SKYLAKE_MOBILE,  skl_rapl_init),
 	X86_RAPL_MODEL_MATCH(INTEL_FAM6_SKYLAKE_DESKTOP, skl_rapl_init),
+	X86_RAPL_MODEL_MATCH(INTEL_FAM6_SKYLAKE_X,	 hsx_rapl_init),
 	{},
 };
 
_

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web