On Thu, Jul 14, 2016 at 11:31:08AM +0100, Emil Velikov wrote: > On 13 July 2016 at 14:34, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > >> > >> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
