[Intel-gfx] RFC: i915 arch changes to better support new chipsets

[Jesse Barnes]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120320/c2d8f866/attachment.sig>