[Intel-gfx] [PATCH igt 01/17] lib: Start weaning off defunct intel_chipset.h

[Chris Wilson]

On Thu, Jul 14, 2016 at 11:31:08AM +0100, Emil Velikov wrote:
> On 13 July 2016 at 14:34, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Wed, Jul 13, 2016 at 02:40:49PM +0200, Daniel Vetter wrote:
> >> On Wed, Jun 29, 2016 at 12:38:51PM +0100, Chris Wilson wrote:
> >> > Several years ago we made the plan of only having one canonical source
> >> > for i915_pciids.h, the kernel and everyone importing their definitions
> >> > from that. For consistency, we style the intel_device_info after the
> >> > kernel, most notably using a generation mask and a per-codename bitfield.
> >> >
> >> > This first step converts looking up the generation for a devid tree from
> >> > a massive if(devid)-chain to a (cached) table lookup.
> >> >
> >> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>
> >> Should we extract the kernels list of chipset into intel_chipset.c too, to
> >> make them 1:1 copies like with i915_pciids.h? With that this (entire
> >> series) here has my ack. Without I'm not sold that much on the churn
> >> really.
> >
> > Hmm, next up would be libdrm which is almost a duplication of igt (and
> > can be massaged to be so). The next step would be feeding back the
> > commonality into the kernel, so that we really do have a single location
> > where we need to add new defines that can just percolate through.
> >
> > So I think you mean to have the device-info stanzas shared...
> 
> Fwiw I would suggest the same thing - have this this code in a single
> place (be that kernel or libdrm) accessible by everyone. Otherwise
> others (libva/beignet/mesa?) will copy it and it'll be a constant
> chance to keep it in sync.

That's what we said many years ago! Still trying to get there.
 
> About the patch itself here are a few small nitpicks:
>  - intel_i81x_info seems to be unused

One day! One day we will have that universal kms driver!

(It's required for the ddx at least, so I should hook up the ids as well
but really needs inclusion in i915_pciids.h first.)

>  - s/aaglelake/eaglelake/
>  - capitalise the first letter of each codename ?

Code already utilized codenames with the lowercase as filenames (for
register sets). I thought about making it call lowercase() - it was just
easier to match captilisation.

>  - Wikipedia lists Bearlake and Lakeport in both Gen3 and Gen4. Is it
> busted or ...

Or a confusion between chipset and GPU.

>From bspec,

915G, Grantsdale-G, GDG
915GM, Alviso, ALV
945G, Lakport, LPT,
945GM, Callistoga, CST

Bearlake-B is listed for gen3, but that chipset shared more in common
with the early gen4 GMCH.

>  - Ironlake, Clarkdale is listed as Ironlake, while Ironlake,
> Arrandale as Arrandale. Guess those are the names people are more used
> to ?

It's just DevILK in the bspec, I'd forgotten Clarkdale but remembered
Arrandale as the mobile variant (and I wasn't actually sure if Clarkdale
was just the GPU-less chips). But since it is DevILK, we probably
should just use Ironlake, hmm or we list all the shortnames as well for
better cross-referencing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre