[Intel-gfx] [PATCH 19/25] drm/i915: display regs are at 0x180000 on ValleyView

[Jesse Barnes]

On Wed, 21 Mar 2012 14:36:47 -0700
Jesse Barnes <jbarnes at virtuousgeek.org> wrote:

> On Wed, 21 Mar 2012 22:33:43 +0100
> Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> > On Wed, Mar 21, 2012 at 12:48:40PM -0700, Jesse Barnes wrote:
> > > Although internally the MMIO offsets for display regs haven't changed,
> > > their visibility through the PCI BAR has been affected by the addition
> > > of the Gunit, which occupies the low part of the address space.
> > > 
> > > Display regs on VLV are offset into the BAR by 0x180000, so we need to
> > > add that for any display register offset.
> > > 
> > > This patch is a hack to do just that, but ultimately we need to split
> > > our display and render code more cleanly and add accessor functions for
> > > them.
> > > 
> > > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> > 
> > Gosh, is this horrible ;-) I think a dev_priv->display_mmio_base like
> > you've proposed + I915_DISPLAY_READ/WRITE like we already have for the
> > ring stuff is much better ...
> 
> I nearly got violent with the hw guys when they told me...
> 
> But yeah I think a display reg wrapper with an offset is probably the
> least offensive.

Ok started on this but quickly got frustrated.  Should we apply this
everywhere, even to PCH and ilk+ stuff?  If not, it'll get
inconsistent, if we do, it'll be confusing.

I wonder if we should split intel_display.c first, and only apply the
new macro to the gmch code?  But that still leaves the various port
files and gpio/gmbus... but those have pretty clear PCH splits too
right?

Suggestions welcome, but there may be no way to avoid a complete audit
of every single read/write to see if it should be converted (ugg).

-- 
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/20120322/67f80720/attachment.sig>