[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2018 16:07:04 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andi Kleen <ak@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
kan.liang@...ux.intel.com, Ingo Molnar <mingo@...hat.com>,
Len Brown <len.brown@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Wed, Aug 8, 2018 at 7:16 AM Thomas Gleixner <tglx@...utronix.de> 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_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
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
Powered by blists - more mailing lists