[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180807221725.GU4238@tassilo.jf.intel.com>
Date: Tue, 7 Aug 2018 15:17:25 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
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
> 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
Powered by blists - more mailing lists