Message ID | 20160603001927.F2A7D828@viggo.jf.intel.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Thursday, June 02, 2016 05:19:27 PM Dave Hansen wrote: > > Changes from v1: > * added acks from a few folks > * Took the redundant "MODEL_" out of the macro names (Suggested > by Borislav Petkov and acked by others) > > From: Dave Hansen <dave.hansen@linux.intel.com> > > If you are cc'd on this code, please check _your_ code vs. the > model list in "intel-family.h". Please make sure you have all > the models listed that you intend to. > > Also, rather than trickling these in via all the various > maintainers, should these just get pulled in to the x86 tree in > one go? Yes, please. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Dave Hansen <dave@sr71.net> wrote: > > Changes from v1: > * added acks from a few folks > * Took the redundant "MODEL_" out of the macro names (Suggested > by Borislav Petkov and acked by others) > > From: Dave Hansen <dave.hansen@linux.intel.com> > > If you are cc'd on this code, please check _your_ code vs. the > model list in "intel-family.h". Please make sure you have all > the models listed that you intend to. > > Also, rather than trickling these in via all the various > maintainers, should these just get pulled in to the x86 tree in > one go? > > Problem: > > We have a boatload of open-coded family-6 model numbers. Half of > them have these model numbers in hex and the other half in > decimal. This makes grepping for them tons of fun, if you were > to try. > > Solution: > > Consolidate all the magic numbers. Put all the definitions in > one header. > > The names here are closely derived from the comments describing > the models from arch/x86/events/intel/core.c. We could easily > make them shorter by doing things like s/SANDYBRIDGE/SNB/, but > they seemed fine even with the longer versions to me. > > Do not take any of these names too literally, like "DESKTOP" > or "MOBILE". These are all colloquial names and not precise > descriptions of everywhere a given model will show up. > > These have all been compile-tested. I also made a stab at > dumping .o files and looking for unexpected deltas when I was > just replacing magic numbers with equivalent macros. So I've picked up this series and restructured it: I've created a single patch that creates intel-family.h and have put it into x86/urgent. This eliminated dependencies and allowed some of the patches to be queued in their natural trees, in particular the 7 perf patches. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -puN /dev/null arch/x86/include/asm/intel-family.h --- /dev/null 2016-04-04 09:40:43.435149254 -0700 +++ b/arch/x86/include/asm/intel-family.h 2016-06-02 17:17:24.254885108 -0700 @@ -0,0 +1,62 @@ +#ifndef _ASM_X86_INTEL_FAMILY_H +#define _ASM_X86_INTEL_FAMILY_H + +/* + * "Big Core" Processors (Branded as Core, Xeon, etc...) + * + * The "_X" parts are generally the EP and EX Xeons, or the + * "Extreme" ones, like Broadwell-E. + */ + +#define INTEL_FAM6_CORE_YONAH 0x0E +#define INTEL_FAM6_CORE2_MEROM 0x0F +#define INTEL_FAM6_CORE2_MEROM_L 0x16 +#define INTEL_FAM6_CORE2_PENRYN 0x17 +#define INTEL_FAM6_CORE2_DUNNINGTON 0x1D + +#define INTEL_FAM6_NEHALEM 0x1E +#define INTEL_FAM6_NEHALEM_EP 0x1A +#define INTEL_FAM6_NEHALEM_EX 0x2E +#define INTEL_FAM6_WESTMERE 0x25 +#define INTEL_FAM6_WESTMERE_EP 0x2C +#define INTEL_FAM6_WESTMERE_EX 0x2F + +#define INTEL_FAM6_SANDYBRIDGE 0x2A +#define INTEL_FAM6_SANDYBRIDGE_X 0x2D +#define INTEL_FAM6_IVYBRIDGE 0x3A +#define INTEL_FAM6_IVYBRIDGE_X 0x3E + +#define INTEL_FAM6_HASWELL_CORE 0x3C +#define INTEL_FAM6_HASWELL_X 0x3F +#define INTEL_FAM6_HASWELL_ULT 0x45 +#define INTEL_FAM6_HASWELL_GT3E 0x46 + +#define INTEL_FAM6_BROADWELL_CORE 0x3D +#define INTEL_FAM6_BROADWELL_XEON_D 0x56 +#define INTEL_FAM6_BROADWELL_GT3E 0x47 +#define INTEL_FAM6_BROADWELL_X 0x4F + +#define INTEL_FAM6_SKYLAKE_MOBILE 0x4E +#define INTEL_FAM6_SKYLAKE_DESKTOP 0x5E +#define INTEL_FAM6_SKYLAKE_X 0x55 +#define INTEL_FAM6_KABYLAKE_MOBILE 0x8E +#define INTEL_FAM6_KABYLAKE_DESKTOP 0x9E + +/* "Small Core" Processors (Atom) */ + +#define INTEL_FAM6_ATOM_PINEVIEW 0x1C +#define INTEL_FAM6_ATOM_LINCROFT 0x26 +#define INTEL_FAM6_ATOM_PENWELL 0x27 +#define INTEL_FAM6_ATOM_CLOVERVIEW 0x35 +#define INTEL_FAM6_ATOM_CEDARVIEW 0x36 +#define INTEL_FAM6_ATOM_SILVERMONT1 0x37 +#define INTEL_FAM6_ATOM_SILVERMONT2 0x4D /* Avaton/Rangely */ +#define INTEL_FAM6_ATOM_AIRMONT 0x4C +#define INTEL_FAM6_ATOM_GOLDMONT 0x5C +#define INTEL_FAM6_ATOM_DENVERTON 0x5F /* Goldmont Microserver */ + +/* Xeon Phi */ + +#define INTEL_FAM6_XEON_PHI_KNL 0x57 /* Knights Landing */ + +#endif /* _ASM_X86_INTEL_FAMILY_H */