[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1809271648210.8118@nanos.tec.linutronix.de>
Date: Thu, 27 Sep 2018 16:49:18 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
kan.liang@...ux.intel.com, mingo@...hat.com, len.brown@...el.com,
linux-kernel@...r.kernel.org, x86@...nel.org
Subject: 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_X 0x3F
> > #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_SILVERMONT 0x37 /* Bay Trail, Valleyview */
> #define INTEL_FAM6_ATOM_SILVERMONT_X 0x4D /* 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_GOLDMONT 0x5C /* Apollo Lake */
> #define INTEL_FAM6_ATOM_GOLDMONT_X 0x5F /* Denvertor */
> #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */
Thanks for doing that!
> ---
> Subject: x86/cpu: Sanitize FAM6_ATOM naming
> From: Peter Zijlstra <peterz@...radead.org>
> 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: x86@...nel.org
> Cc: mingo@...hat.com
> Cc: ak@...ux.intel.com
> Cc: tglx@...utronix.de
> Cc: dave.hansen@...ux.intel.com
> Cc: len.brown@...el.com
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Which way do we route that?
Thanks,
tglx
Powered by blists - more mailing lists