Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 27 Sep 2018 16:49:18 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Peter Zijlstra <peterz@infradead.org>
cc:     Andi Kleen <ak@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        kan.liang@linux.intel.com, mingo@redhat.com, len.brown@intel.com,
        linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
In-Reply-To: <20180927142519.GB3439@hirez.programming.kicks-ass.net>
Message-ID: <alpine.DEB.2.21.1809271648210.8118@nanos.tec.linutronix.de>
References: <1533662247-17575-1-git-send-email-kan.liang@linux.intel.com> <1b7cb461-5321-86cf-3031-5ff545c3dc42@linux.intel.com> <20180807174851.GJ2494@hirez.programming.kicks-ass.net> <20180807183736.GR4238@tassilo.jf.intel.com>
 <alpine.DEB.2.21.1808072257080.1672@nanos.tec.linutronix.de> <20180807221725.GU4238@tassilo.jf.intel.com> <alpine.DEB.2.21.1808080653120.1672@nanos.tec.linutronix.de> <20180927142519.GB3439@hirez.programming.kicks-ass.net>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@infradead.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@kernel.org
> Cc: mingo@redhat.com
> Cc: ak@linux.intel.com
> Cc: tglx@linutronix.de
> Cc: dave.hansen@linux.intel.com
> Cc: len.brown@intel.com
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Which way do we route that?

Thanks,

	tglx