Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Fri, Sep 28, 2018 at 05:07:04PM +0100, Alan Cox wrote: > > > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview > > There is no such product as Valleyview. Some things talk about > Valleyview 2 but shouldn't as that is Baytrail. I couldn't find it either, but it is all over the linux code. I'd be happy to remove it from this comment though. > > /* "Small Core" Processors (Atom) */ > > > > #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview > > */ > > #define INTEL_FAM6_ATOM_BONNELL_MID 0x26 /* Silverthorne, Lincroft */ > > > > #define INTEL_FAM6_ATOM_SALTWELL0x36 /* Cedarview */ > > #define INTEL_FAM6_ATOM_SALTWELL_MID0x27 /* Penwell */ > > #define INTEL_FAM6_ATOM_SALTWELL_TABLET 0x35 /* Cloverview */ > > > > #define INTEL_FAM6_ATOM_SILVERMONT 0x37 /* Bay Trail, Valleyview */ > > #define INTEL_FAM6_ATOM_SILVERMONT_X0x4D /* Avaton, Rangely */ > > #define INTEL_FAM6_ATOM_SILVERMONT_MID 0x4A /* Merriefield */ > > > > #define INTEL_FAM6_ATOM_AIRMONT 0x4C /* Cherry Trail, Braswell > > */ > > #define INTEL_FAM6_ATOM_AIRMONT_MID 0x5A /* Moorefield */ > > > > #define INTEL_FAM6_ATOM_GOLDMONT0x5C /* Apollo Lake */ > > #define INTEL_FAM6_ATOM_GOLDMONT_X 0x5F /* Denvertor */ > > #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ > > Can you decide if you are going to consistently use the -view or the > -trail naming ? I think for our use cases you mean Pinetrail, Cedartrail, > Clovertrail, Cherrytrail as you are talking about platform (at least in > the Intel sense of the word). Like I said; I went with whatever is on this here page: https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors There is no Cedar Trail, or Bayview. If you could do me a delta patch with the names you think are appropriate i'd be happy to fold it in. Alternatively, I can remove the tail comments entirely. I spend entirely too much time already trying to come up with sensible names already.
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview There is no such product as Valleyview. Some things talk about Valleyview 2 but shouldn't as that is Baytrail. > /* "Small Core" Processors (Atom) */ > > #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview > */ > #define INTEL_FAM6_ATOM_BONNELL_MID 0x26 /* Silverthorne, Lincroft */ > > #define INTEL_FAM6_ATOM_SALTWELL 0x36 /* Cedarview */ > #define INTEL_FAM6_ATOM_SALTWELL_MID 0x27 /* Penwell */ > #define INTEL_FAM6_ATOM_SALTWELL_TABLET 0x35 /* Cloverview */ > > #define INTEL_FAM6_ATOM_SILVERMONT0x37 /* Bay Trail, Valleyview */ > #define INTEL_FAM6_ATOM_SILVERMONT_X 0x4D /* Avaton, Rangely */ > #define INTEL_FAM6_ATOM_SILVERMONT_MID0x4A /* Merriefield */ > > #define INTEL_FAM6_ATOM_AIRMONT 0x4C /* Cherry Trail, Braswell > */ > #define INTEL_FAM6_ATOM_AIRMONT_MID 0x5A /* Moorefield */ > > #define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */ > #define INTEL_FAM6_ATOM_GOLDMONT_X0x5F /* Denvertor */ > #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ Can you decide if you are going to consistently use the -view or the -trail naming ? I think for our use cases you mean Pinetrail, Cedartrail, Clovertrail, Cherrytrail as you are talking about platform (at least in the Intel sense of the word). Alan
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Thu, 27 Sep 2018, Peter Zijlstra wrote: > On Thu, Sep 27, 2018 at 04:49:18PM +0200, Thomas Gleixner wrote: > > > Subject: x86/cpu: Sanitize FAM6_ATOM naming > > > From: Peter Zijlstra > > > Date: Tue, 7 Aug 2018 10:17:27 -0700 > > > > > > Going primarily by: > > > > > > > > > https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Silvermont_microarchitecture > > > > > > with additional information gleaned from other related pages; notably: > > > > > > - Bonnell shrink was called Saltwell > > > - Moorefield is the Merriefield refresh which makes it Airmont > > > > > > The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE > > > > > > Cc: x...@kernel.org > > > Cc: mi...@redhat.com > > > Cc: a...@linux.intel.com > > > Cc: t...@linutronix.de > > > Cc: dave.han...@linux.intel.com > > > Cc: len.br...@intel.com > > > Signed-off-by: Peter Zijlstra (Intel) > > > > Which way do we route that? > > I have it stuck in with some perf patches, does that work? Sure. We just should do a quick check against -next for the files outside the tip realm. Thanks, tglx
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Thu, Sep 27, 2018 at 04:49:18PM +0200, Thomas Gleixner wrote: > > Subject: x86/cpu: Sanitize FAM6_ATOM naming > > From: Peter Zijlstra > > Date: Tue, 7 Aug 2018 10:17:27 -0700 > > > > Going primarily by: > > > > > > https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Silvermont_microarchitecture > > > > with additional information gleaned from other related pages; notably: > > > > - Bonnell shrink was called Saltwell > > - Moorefield is the Merriefield refresh which makes it Airmont > > > > The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE > > > > Cc: x...@kernel.org > > Cc: mi...@redhat.com > > Cc: a...@linux.intel.com > > Cc: t...@linutronix.de > > Cc: dave.han...@linux.intel.com > > Cc: len.br...@intel.com > > Signed-off-by: Peter Zijlstra (Intel) > > Which way do we route that? I have it stuck in with some perf patches, does that work?
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On 09/27/2018 07:25 AM, Peter Zijlstra wrote: > #define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */ > #define INTEL_FAM6_ATOM_GOLDMONT_X0x5F /* Denvertor */ > #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ s/Denvertor/Denverton/ But, yeah, that list looks consistent and sane.
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Thu, 27 Sep 2018, Peter Zijlstra wrote: > On Wed, Aug 08, 2018 at 07:14:52AM +0200, Thomas Gleixner wrote: > > > We have that for the big cores as well: > > > > #define INTEL_FAM6_HASWELL_CORE 0x3C > > #define INTEL_FAM6_HASWELL_X0x3F > > #define INTEL_FAM6_HASWELL_ULT 0x45 > > #define INTEL_FAM6_HASWELL_GT3E 0x46 > > > > Why would we treat ATOM differently? It's all the same scheme: > > > > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview > > SILVERMONT_SERVER 0x40 Avaton, Rangely > > > > and on goldmont it's not any different. > > > > We really want one scheme for both Core and ATOM and not randomly picked > > different ones. For the kernel (aside of some peripheral stuff) the most > > interesting information is the UARCH plus the extra features which are > > enabled on a particular SoC. > > > > The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2 > > variants are in fact CLIENT/SERVER and the comment in the header file, that > > there is no better name, is just silly. > > OK, I spend a lot of time googling various things and came up with the > below. TL;DR: > > /* "Small Core" Processors (Atom) */ > > #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview > */ > #define INTEL_FAM6_ATOM_BONNELL_MID 0x26 /* Silverthorne, Lincroft */ > > #define INTEL_FAM6_ATOM_SALTWELL 0x36 /* Cedarview */ > #define INTEL_FAM6_ATOM_SALTWELL_MID 0x27 /* Penwell */ > #define INTEL_FAM6_ATOM_SALTWELL_TABLET 0x35 /* Cloverview */ > > #define INTEL_FAM6_ATOM_SILVERMONT0x37 /* Bay Trail, Valleyview */ > #define INTEL_FAM6_ATOM_SILVERMONT_X 0x4D /* Avaton, Rangely */ > #define INTEL_FAM6_ATOM_SILVERMONT_MID0x4A /* Merriefield */ > > #define INTEL_FAM6_ATOM_AIRMONT 0x4C /* Cherry Trail, Braswell > */ > #define INTEL_FAM6_ATOM_AIRMONT_MID 0x5A /* Moorefield */ > > #define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */ > #define INTEL_FAM6_ATOM_GOLDMONT_X0x5F /* Denvertor */ > #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ Thanks for doing that! > --- > Subject: x86/cpu: Sanitize FAM6_ATOM naming > From: Peter Zijlstra > Date: Tue, 7 Aug 2018 10:17:27 -0700 > > Going primarily by: > > > https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Silvermont_microarchitecture > > with additional information gleaned from other related pages; notably: > > - Bonnell shrink was called Saltwell > - Moorefield is the Merriefield refresh which makes it Airmont > > The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE > > Cc: x...@kernel.org > Cc: mi...@redhat.com > Cc: a...@linux.intel.com > Cc: t...@linutronix.de > Cc: dave.han...@linux.intel.com > Cc: len.br...@intel.com > Signed-off-by: Peter Zijlstra (Intel) Which way do we route that? Thanks, tglx
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Wed, Aug 08, 2018 at 07:14:52AM +0200, Thomas Gleixner wrote: > We have that for the big cores as well: > > #define INTEL_FAM6_HASWELL_CORE 0x3C > #define INTEL_FAM6_HASWELL_X0x3F > #define INTEL_FAM6_HASWELL_ULT 0x45 > #define INTEL_FAM6_HASWELL_GT3E 0x46 > > Why would we treat ATOM differently? It's all the same scheme: > > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview > SILVERMONT_SERVER 0x40 Avaton, Rangely > > and on goldmont it's not any different. > > We really want one scheme for both Core and ATOM and not randomly picked > different ones. For the kernel (aside of some peripheral stuff) the most > interesting information is the UARCH plus the extra features which are > enabled on a particular SoC. > > The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2 > variants are in fact CLIENT/SERVER and the comment in the header file, that > there is no better name, is just silly. OK, I spend a lot of time googling various things and came up with the below. TL;DR: /* "Small Core" Processors (Atom) */ #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ #define INTEL_FAM6_ATOM_BONNELL_MID 0x26 /* Silverthorne, Lincroft */ #define INTEL_FAM6_ATOM_SALTWELL0x36 /* Cedarview */ #define INTEL_FAM6_ATOM_SALTWELL_MID0x27 /* Penwell */ #define INTEL_FAM6_ATOM_SALTWELL_TABLET 0x35 /* Cloverview */ #define INTEL_FAM6_ATOM_SILVERMONT 0x37 /* Bay Trail, Valleyview */ #define INTEL_FAM6_ATOM_SILVERMONT_X0x4D /* Avaton, Rangely */ #define INTEL_FAM6_ATOM_SILVERMONT_MID 0x4A /* Merriefield */ #define INTEL_FAM6_ATOM_AIRMONT 0x4C /* Cherry Trail, Braswell */ #define INTEL_FAM6_ATOM_AIRMONT_MID 0x5A /* Moorefield */ #define INTEL_FAM6_ATOM_GOLDMONT0x5C /* Apollo Lake */ #define INTEL_FAM6_ATOM_GOLDMONT_X 0x5F /* Denvertor */ #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ --- Subject: x86/cpu: Sanitize FAM6_ATOM naming From: Peter Zijlstra Date: Tue, 7 Aug 2018 10:17:27 -0700 Going primarily by: https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Silvermont_microarchitecture with additional information gleaned from other related pages; notably: - Bonnell shrink was called Saltwell - Moorefield is the Merriefield refresh which makes it Airmont The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE Cc: x...@kernel.org Cc: mi...@redhat.com Cc: a...@linux.intel.com Cc: t...@linutronix.de Cc: dave.han...@linux.intel.com Cc: len.br...@intel.com Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/events/intel/core.c | 20 --- arch/x86/events/intel/cstate.c|8 +-- arch/x86/events/intel/rapl.c |4 - arch/x86/events/msr.c |8 +-- arch/x86/include/asm/intel-family.h | 33 ++-- arch/x86/kernel/cpu/common.c | 24 - arch/x86/kernel/tsc.c |2 arch/x86/kernel/tsc_msr.c |4 - arch/x86/platform/atom/punit_atom_debug.c |4 - arch/x86/platform/intel-mid/device_libs/platform_bt.c |2 drivers/acpi/acpi_lpss.c |2 drivers/acpi/x86/utils.c |2 drivers/cpufreq/intel_pstate.c|4 - drivers/edac/pnd2_edac.c |2 drivers/idle/intel_idle.c | 18 +++ drivers/mmc/host/sdhci-acpi.c |2 drivers/pci/pci-mid.c |4 - drivers/platform/x86/intel_int0002_vgpio.c|2 drivers/platform/x86/intel_mid_powerbtn.c |4 - drivers/platform/x86/intel_telemetry_debugfs.c|2 drivers/platform/x86/intel_telemetry_pltdrv.c |2 drivers/powercap/intel_rapl.c | 10 +-- drivers/thermal/intel_soc_dts_thermal.c |2 sound/soc/intel/boards/bytcr_rt5651.c |2 tools/power/x86/turbostat/turbostat.c | 46 +- 25 files changed, 108 insertions(+), 105 deletions(-) --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4121,11 +4121,11 @@ __init int intel_pmu_init(void) name = "nehalem"; break; - case INTEL_FAM6_ATOM_PINEVIEW: - case INTEL_FAM6_ATOM_LINCROFT: - case INTEL_FAM6_ATOM_PENWELL: - case INTEL_FAM6_ATOM_CLOVERVIEW: - case INTEL_FAM6_ATOM_CEDARVIEW: + case INTEL_FAM6_ATOM_BONNELL: + case INTEL_FAM6_ATOM_BONNELL_MID: + case INTEL_FAM6_ATOM_SALTWELL: + case INTEL_FAM6_ATOM_SALTWELL_MID: + case INTEL_FAM6_ATOM_SALTWELL_TABLET: memcpy(hw_cache_event_ids, atom_hw_cache_event_ids, siz
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Wed, Aug 8, 2018 at 7:16 AM Thomas Gleixner wrote: > On Tue, 7 Aug 2018, Andi Kleen wrote: > > > It's even worse with Silvermont. > > > > > > So no, the interesting information is the UARCH and the variant of that, > > > > With Uarch you mean the core uarch? That doesn't really work for > > something like Silvermont or Goldmont. > > > > > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names > > > > Right your scheme totally doesn't work on Silvermont because there > > are multiple client variants. > > We have that for the big cores as well: > > #define INTEL_FAM6_HASWELL_CORE 0x3C > #define INTEL_FAM6_HASWELL_X0x3F > #define INTEL_FAM6_HASWELL_ULT 0x45 > #define INTEL_FAM6_HASWELL_GT3E 0x46 > > Why would we treat ATOM differently? It's all the same scheme: > > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview > SILVERMONT_SERVER 0x40 Avaton, Rangely 0x5D SoFIA is another Silvermont variant on the client side, and doesn't fit well in that scheme I'd say. Calling it SILVERMONT_SOFIA would probably be best here so people can figure out what it is. Arnd
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, 7 Aug 2018, Andi Kleen wrote: > > Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > > with that Fam/Model combination are: > > > > - Apollo Lake > > - Broxton (has two platforms: Morganfield and Willowtrail) > > Right pick one. The others are the same for software purposes > and can be handled in the same way. Pick one is really not a good choice. > > It's even worse with Silvermont. > > > > So no, the interesting information is the UARCH and the variant of that, > > With Uarch you mean the core uarch? That doesn't really work for > something like Silvermont or Goldmont. > > > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names > > Right your scheme totally doesn't work on Silvermont because there > are multiple client variants. We have that for the big cores as well: #define INTEL_FAM6_HASWELL_CORE 0x3C #define INTEL_FAM6_HASWELL_X0x3F #define INTEL_FAM6_HASWELL_ULT 0x45 #define INTEL_FAM6_HASWELL_GT3E 0x46 Why would we treat ATOM differently? It's all the same scheme: SILVERMONT_CLIENT 0x37 Baytrail, Valleyview SILVERMONT_SERVER 0x40 Avaton, Rangely and on goldmont it's not any different. We really want one scheme for both Core and ATOM and not randomly picked different ones. For the kernel (aside of some peripheral stuff) the most interesting information is the UARCH plus the extra features which are enabled on a particular SoC. The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2 variants are in fact CLIENT/SERVER and the comment in the header file, that there is no better name, is just silly. Thanks, tglx
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
> Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > with that Fam/Model combination are: > > - Apollo Lake > - Broxton (has two platforms: Morganfield and Willowtrail) Right pick one. The others are the same for software purposes and can be handled in the same way. > > It's even worse with Silvermont. > > So no, the interesting information is the UARCH and the variant of that, With Uarch you mean the core uarch? That doesn't really work for something like Silvermont or Goldmont. > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names Right your scheme totally doesn't work on Silvermont because there are multiple client variants. > and their platform variants are not interesting at all for the Fam/Model > information. You're right platform is misleading. I think the right level are SOCs, because that matches the how the model numbers are allocated. On Big Core *Lakes are all unique SOCs. -Andi
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, 7 Aug 2018, Andi Kleen wrote: > On Tue, Aug 07, 2018 at 07:48:51PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > > > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > > > Denverton and Gemini Lake are platform names and should not be used for > > > > Processor Family stuff. The microarchitecture codename should be used. > > > > > > Why? > > > > > > Denverton is the platform. "Goldmont" is literally the > > > microarchitecture, and you are suggesting moving *to* the > > > microarchitecture name, which contradicts the description. > > > > All the other (big core) are uarch names. Atom is weird in that it mixes > > uarch with platform names. > > On most big core the platform/SOC just happens to have the same name as the > uarch. But the identifiers really have to be per SOC because that > is how Intel model numbers work. > > It should be always the SOC. Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs with that Fam/Model combination are: - Apollo Lake - Broxton (has two platforms: Morganfield and Willowtrail) It's even worse with Silvermont. So no, the interesting information is the UARCH and the variant of that, e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names and their platform variants are not interesting at all for the Fam/Model information. Thanks, tglx
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, Aug 07, 2018 at 11:37:36AM -0700, Andi Kleen wrote: > On Tue, Aug 07, 2018 at 07:48:51PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > > > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > > > Denverton and Gemini Lake are platform names and should not be used for > > > > Processor Family stuff. The microarchitecture codename should be used. > > > > > > Why? > > > > > > Denverton is the platform. "Goldmont" is literally the > > > microarchitecture, and you are suggesting moving *to* the > > > microarchitecture name, which contradicts the description. > > > > All the other (big core) are uarch names. Atom is weird in that it mixes > > uarch with platform names. > > On most big core the platform/SOC just happens to have the same name as the > uarch. But the identifiers really have to be per SOC because that > is how Intel model numbers work. I'm sure that is how we ended up with two SKX parts with identical model numbers but different crystal frequencies :-( Let's just keep consistency and use MICROARCH_TYPE things for everything.
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, Aug 07, 2018 at 07:48:51PM +0200, Peter Zijlstra wrote: > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > > Denverton and Gemini Lake are platform names and should not be used for > > > Processor Family stuff. The microarchitecture codename should be used. > > > > Why? > > > > Denverton is the platform. "Goldmont" is literally the > > microarchitecture, and you are suggesting moving *to* the > > microarchitecture name, which contradicts the description. > > All the other (big core) are uarch names. Atom is weird in that it mixes > uarch with platform names. On most big core the platform/SOC just happens to have the same name as the uarch. But the identifiers really have to be per SOC because that is how Intel model numbers work. It should be always the SOC. -Andi
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, Aug 07, 2018 at 10:17:27AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Denverton and Gemini Lake are platform names and should not be used for > Processor Family stuff. The microarchitecture codename should be used. > > DENVERTON is Goldmont server SoC. Rename DENVERTON to GOLDMONT2, similar > to SILVERMONT2 being the silvermont server SoCs. > > Rename GEMINI_LAKE to GOLDMONT_PLUS. That doesn't make sense. Goldmont Plus can be in other SOCs with different Model numbers too. 0x7a really means Gemini Lake SOC, but not all systems containing a Goldmont Plus. Also all the other identifiers are for SOCs too. -Andi
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On 08/07/2018 10:48 AM, Peter Zijlstra wrote: > On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: >> On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: >>> Denverton and Gemini Lake are platform names and should not be used for >>> Processor Family stuff. The microarchitecture codename should be used. >> Why? >> >> Denverton is the platform. "Goldmont" is literally the >> microarchitecture, and you are suggesting moving *to* the >> microarchitecture name, which contradicts the description. > All the other (big core) are uarch names. Atom is weird in that it mixes > uarch with platform names. Good point. Feel free to add: Acked-by: Dave Hansen
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, Aug 07, 2018 at 10:35:42AM -0700, Dave Hansen wrote: > On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > > Denverton and Gemini Lake are platform names and should not be used for > > Processor Family stuff. The microarchitecture codename should be used. > > Why? > > Denverton is the platform. "Goldmont" is literally the > microarchitecture, and you are suggesting moving *to* the > microarchitecture name, which contradicts the description. All the other (big core) are uarch names. Atom is weird in that it mixes uarch with platform names.
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On 08/07/2018 10:17 AM, kan.li...@linux.intel.com wrote: > Denverton and Gemini Lake are platform names and should not be used for > Processor Family stuff. The microarchitecture codename should be used. Why? Denverton is the platform. "Goldmont" is literally the microarchitecture, and you are suggesting moving *to* the microarchitecture name, which contradicts the description. I'm confused.
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, Aug 07, 2018 at 10:17:27AM -0700, kan.li...@linux.intel.com wrote: > From: Kan Liang > > Denverton and Gemini Lake are platform names and should not be used for > Processor Family stuff. The microarchitecture codename should be used. > > DENVERTON is Goldmont server SoC. Rename DENVERTON to GOLDMONT2, similar > to SILVERMONT2 being the silvermont server SoCs. > > Rename GEMINI_LAKE to GOLDMONT_PLUS. > > Suggested-by: Peter Zijlstra (Intel) > Signed-off-by: Kan Liang Thanks! the alternative to 2 is _X like we have with the big cores to denote server chips, but this is already a nice improvement.
