From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: RFC: i915 arch changes to better support new chipsets Date: Tue, 20 Mar 2012 11:13:57 -0700 Message-ID: <20120320111357.56093868@jbarnes-desktop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0229868519==" Return-path: Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by gabe.freedesktop.org (Postfix) with SMTP id 4E5D9A0A6C for ; Tue, 20 Mar 2012 11:14:08 -0700 (PDT) Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189] helo=jbarnes-desktop) by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SA3ZO-0004eJ-6x for intel-gfx@lists.freedesktop.org; Tue, 20 Mar 2012 12:14:06 -0600 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: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0229868519== Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/BfFt6MN.uLHUaRs0R4r8X6q"; protocol="application/pgp-signature" --Sig_/BfFt6MN.uLHUaRs0R4r8X6q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've been talking with some people offline about potential changes to our source structure to make it easier to add support for new chipsets, prevent breaking chipsets one doesn't intend to affect, and generally make the code more readable and maintainable. I've got some new chipset code ready that's motivating some of this work, because it moved all the display regs around, added a new unit in low MMIO space, and generally affects gen7 paths with gen5 like behavior. The question is, how far should we go? At the very least, I'd like to propose the following: intel_display.c -> pch_display.c, gmch_display.c, potentially with additional sub-files for specific weirdness and power/drps functionality i915_irq.c -> per chipset irq files (i9xx, ironlake, ivb at the very least, with some additional duplication) 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 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. 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). 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+... Thanks, --=20 Jesse Barnes, Intel Open Source Technology Center --Sig_/BfFt6MN.uLHUaRs0R4r8X6q Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPaMjlAAoJEIEoDkX4Qk9hw50QAIC69hBXvWEy5xVwLQMOSGFM CUheoysLw0nZftBenTfe3ANgr8SVKRTWcdIwQBEGrLbIYN+UyqOYCOJuz+y/TOQc IQqFkve54BXkX/qpYSyEXIcQAWjxPKU9nOufoobHMuMnb0cyDwF63DN7OvNj3fsN QpzHGtGemnY4VwCLBJiDH6rZphLMC7pntMvnOrAQ+eHODQAm5H5iobMXcDgTAviO 4yJ9uZG7S4ic/IpsnlFjjHFZmi37ZXRt6F45hPCir8/k3oEwGjQjIz9eSvZCf6zR /ppW1d8A9eTr9iWdReHeBqfCy/jhJaJoXqN74+WIN/u4OPeRifc+AIBFNQauDeo7 RGO0cC11jz/3boXiz2BllyGucCgHC9W5Q9WW2k1M8+MZuA2CCrHZzwX4DrWTsMOB /SvrNxX8y6tt/rqSC2TWuiYpxZ7WrSXw1BbyvgQb7ZF3kdov/N7U/BpPGebbLd9u 8yGUSJaocY0IyZmfhWlK3BhLsjEyOXpybfz6FiPc+2ZvIiqZJY7a5XAa/VX6t9eE YvzNJNiRK1agf17n3H28eYDH8BUwxTRa1wEErx4DRlUQwdbyuWZHnkDJaG2Z8Wxi CQMgDQG6T4DxKeFBB7o76m26H7zMz/z58LFrZqmwC1NNjooY4EDnFG/vl755YM7X wmC2QpCi6yDfVhPMpeDV =i0u6 -----END PGP SIGNATURE----- --Sig_/BfFt6MN.uLHUaRs0R4r8X6q-- --===============0229868519== 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 --===============0229868519==--