From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: intel-gfx@lists.freedesktop.org
Subject: RFC: i915 arch changes to better support new chipsets
Date: Tue, 20 Mar 2012 11:13:57 -0700 [thread overview]
Message-ID: <20120320111357.56093868@jbarnes-desktop> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1676 bytes --]
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,
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2012-03-20 18:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 18:13 Jesse Barnes [this message]
2012-03-20 18:43 ` RFC: i915 arch changes to better support new chipsets Daniel Vetter
2012-03-20 20:13 ` Jesse Barnes
2012-03-21 11:42 ` Eugeni Dodonov
2012-03-21 11:58 ` Chris Wilson
2012-03-21 20:41 ` Jesse Barnes
2012-03-28 19:35 ` Eric Anholt
2012-03-28 19:46 ` Jesse Barnes
2012-03-28 19:59 ` Eugeni Dodonov
2012-03-28 20:29 ` Eric Anholt
2012-03-28 20:37 ` Daniel Vetter
2012-03-29 1:02 ` Eugeni Dodonov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120320111357.56093868@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox