From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: RFC: i915 arch changes to better support new chipsets Date: Wed, 28 Mar 2012 12:35:53 -0700 Message-ID: <871uocldra.fsf@eliezer.anholt.net> References: <20120320111357.56093868@jbarnes-desktop> <20120320184304.GC27231@phenom.ffwll.local> <20120320131347.10427988@jbarnes-desktop> <20120321134121.6eef8b74@jbarnes-desktop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0942386428==" Return-path: In-Reply-To: <20120321134121.6eef8b74@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0942386428== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 21 Mar 2012 13:41:21 -0700, Jesse Barnes = wrote: > On Tue, 20 Mar 2012 13:13:47 -0700 > Jesse Barnes wrote: > > > > I'm open to suggestions on how to fix i915_reg.h; it's becoming qui= te a > > > > beast. Our goal to be to make it easy to add new definitions while > > > > also making it easy to not accidentally use old an incorrect > > > > definitions on a new platform. > > >=20 > > > Close your eyes and just keep on adding gunk. Imo i915_reg.h is pretty > > > much a write-once file, and cscope can still keep up with the definit= ions. > > > So not a pain point for me. >=20 > Oh I forgot the most important thing here: how many f*cking places do > we need to add PCI IDs??!! >=20 > I'd really really like to see i915_reg.h shared to libdrm and used > directly by intel-gpu-tools and Mesa if at all possible, whether we > split it or not. The IS_* and HAS_* macros should be in there as well, > with the PCI IDs, then we can just add this stuff in one place... So, I was thinking about this, but the problem I see is that if we settle on the PCI ID/gen-number identifier being in libdrm, then some distro pulls a new libdrm with hsw bits, and ships the rest of old userland that happily initializes and spits ivb packets at it. I guess we could have the gen-number stuff be a union of IS_IVB()/IS_HSW()/IS_VLV(), and switch chipset probing to using each of those instead of just gen >=3D 4. Does this sound sane? --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk9zaBkACgkQHUdvYGzw6vfmfACeOtU7CZ3mR52oJeoEwSTDtzgu NlkAnRc8OsMBAAr3kqVkd5+9fU3sOEWS =ZfXE -----END PGP SIGNATURE----- --=-=-=-- --===============0942386428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0942386428==--