From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: RFC: i915 arch changes to better support new chipsets Date: Tue, 20 Mar 2012 13:13:47 -0700 Message-ID: <20120320131347.10427988@jbarnes-desktop> References: <20120320111357.56093868@jbarnes-desktop> <20120320184304.GC27231@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0213610513==" Return-path: Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by gabe.freedesktop.org (Postfix) with SMTP id 001F69E7E6 for ; Tue, 20 Mar 2012 13:13:56 -0700 (PDT) In-Reply-To: <20120320184304.GC27231@phenom.ffwll.local> 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: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0213610513== Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/NWr8Jbut42/_i9plgXxj7pX"; protocol="application/pgp-signature" --Sig_/NWr8Jbut42/_i9plgXxj7pX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 20 Mar 2012 19:43:04 +0100 Daniel Vetter wrote: > > new, range specific i915_read/write routines, e.g. i915_read_gt, > > i915_read_display to make forcewake and register block moves easier > > to handle >=20 > I'm not convinced whether this is a great idea if applied all over the > code. For specific cases where a block moves it's imo better to just add a > mmio base for that (like we're doing with the ring ctrl regs, which move > around quite a bit over the various rings and generations). Obviously > adding a small helper is good, but imo we should name it a bit more > specific (if possible). So the problem with VLV is that it has a CedarTrail like display (so some new registers, lots of moved bits, etc) but moved to 0x180000. Not everything has moved, just enough to be painful. For example, the PLLs and some interrupt regs are still in the low range, but pipe & display plane regs have moved. So it's not as simple as doing a single offset and applying it everywhere. We need to only apply it for certain regs, which means touching a bunch of read/write accesses that don't already use a wrapper. And for the ones that use a wrapper, like PIPECONF, we'd need a dev_priv->display_mmio_offset or something? I'm not happy with any solution here, but definitely don't want to upstream my current hack (a new IS_DISPLAYREG() check in read/write that adds the offset if needed). > > I'm open to suggestions on how to fix i915_reg.h; it's becoming quite 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 definitions. > So not a pain point for me. >=20 > > Then obviously within those files there's lots of room for improvement, > > for example in i9xx mode setting we still have some pretty massive > > functions that need to be split (I have patches to do that). > >=20 > > Thoughts? It may also make sense to split some of our port specific > > files where they differ enough from previous platforms. E.g. g4x DP vs > > ironlake+... >=20 > I've just talked about this a bit with Eugeni in the context of Haswell, > and I think we might want to hold of for that code until we move output > stuff all over the place. Yeah I don't want to make HSW any harder than necessary; we can put off splits there. --=20 Jesse Barnes, Intel Open Source Technology Center --Sig_/NWr8Jbut42/_i9plgXxj7pX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPaOT7AAoJEIEoDkX4Qk9h1ggP/004LAsQVdDGkvWT/EL/dNG6 ke6jFumwh0WMo1WHEXPp/RELFyJHBetLX1U+crBjKn4pn8Z4lxF3xiR0A6Z0SNKB Lp5WYxoZqW8AUQi3vTSm5yPjd5l367lAb2WdLHuzez4qmMWNDhmTGanTtLQFXWIp YuDsUk+eL6lgvt4W7qaDsItPoyjBWEkSxVJc3Ml0K/AllooUs/3Jcf/7Uo/IxRxM TGwhl5LQSesLCb4bpIKX+YCb/FApYb0LmkKCXnWMxRghh+FBSqTtwN4gUMg9PL/B 8hm5sUvZzOahGWBv5rLv4UNiGTTn5rfb9VwHNRaK982UCnp/sko+BfvdHknxWjel 2vvoJ388J0kKrX/Ey8oz1yzo6XVc+/IlsNEGtslJABdYiV3BhLuQ6oKtOwQEcPnS icXeZx4Ii/thX7sKZkFoOPuFiflglWykcc/wArpx0lwX3Umus45yBouZIR3rHPx+ UgWPorxWYNKjTbs8U+qwEnxb1wXmQKVLMw8PBcsZASztsK6fAioAYar8wMi7zGXj 3K2GSH2MaLYiVx3FoVtPj7YU38BQmc4atCGYsf9Yspypo997Hu+qO6iLZFsnBlEr 3kFqO5bOZu8fwvJdeV88I7IQkTAJwrUcs+XORCS2SiOD666Txhsrh9sksiJdvsKz GfDnETyNnlFrvgRCOpvp =dClo -----END PGP SIGNATURE----- --Sig_/NWr8Jbut42/_i9plgXxj7pX-- --===============0213610513== 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 --===============0213610513==--