Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

             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