lkml.org 
[lkml]   [2018]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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_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.

Thanks,

tglx


\
 
 \ /
  Last update: 2018-08-08 07:15    [W:1.363 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site