[Intel-gfx] RFC: i915 arch changes to better support new chipsets
eugeni at dodonov.net
Wed Mar 21 12:42:37 CET 2012
On Tue, Mar 20, 2012 at 17:13, Jesse Barnes <jbarnes at virtuousgeek.org>wrote:
> > > 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+...
> > 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.
(I suspect those 2 paragraphs above are enough for a new phoronix article
on HSW already :)).
Yeah, I've been through the same issues as Jesse, and we were talking with
Daniel about this. Our intel_display.c is huge and unnecessarily complex,
and we need to split it at some point if we want to keep our mental sanity.
At least the split of it into intel_display.c and intel_pch_display.c would
simplify the things a lot; and maybe we could add intel_display_gen6.c,
intel_display_gen7.c, intel_display_pch_cpt.c and intel_display_pch_lpt.c
and move those hardware-specific stuff there for simplifying out tasks in
I was also thinking on adding a intel_workarounds.c for handling all the
W/As we have in one place, and having some support for calling them via
callbacks to run specific WAs during the modeset, after suspend/resume
cycle and so on.
For i915_regs.h, I don't think there is a need to split is for now. It is a
nice way to have all the registers in just one place, and at least I never
had a problem with it so far.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Intel-gfx