[Intel-gfx] [PATCH 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework
Chris Wilson
chris at chris-wilson.co.uk
Thu Apr 6 16:05:10 UTC 2017
On Thu, Apr 06, 2017 at 06:46:29PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 06:39:42PM +0300, Mika Kuoppala wrote:
> > +static bool
> > check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > {
> > + bool ret = false;
> > +
> > if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> > - return fpga_check_for_unclaimed_mmio(dev_priv);
> > + ret |= fpga_check_for_unclaimed_mmio(dev_priv);
> >
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > - return vlv_check_for_unclaimed_mmio(dev_priv);
> > + ret |= vlv_check_for_unclaimed_mmio(dev_priv);
> >
> > - return false;
> > + if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv))
> > + ret |= gen6_check_for_fifo_debug(dev_priv);
>
> I'd prefer to keep unclaim vs. wake FIFO separate because the
> unclaimned stuff is only for display registers. In my plan to
> split the uncore lock into gt and display locks the unclaimed
> reg stuff would end up being protected by the display lock rather
> than the gt lock.
I don't think it is much of a hindrance, right? We just split it out when
splitting dpy vs gt. Mika was digging through GTFIFODBG and thought it
had some bits for a sideband underflow...
Random thought, would i915->mmio.writeX[reg < 0x40000](i915, reg, val)
or just push all the decisions to the backend? I hope gcc would be able
to automatically store the function pointer i915->mmio.writeX[reg < 0x40000]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list