On Thu, Sep 18, 2014 at 07:28:48AM +0100, Chris Wilson wrote:
> On Wed, Sep 17, 2014 at 04:59:20PM -0400, Rodrigo Vivi wrote:
> > If it wasn't never enabled by kernel parameter or platform default
> > we can avoid reading registers so many times in vain
>
> Nak.
Well I've merged this for now to reduce fbc impact.
> > Cc: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index a988862..afcc284 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -339,6 +339,12 @@ bool intel_fbc_enabled(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > + /* If it wasn't never enabled by kernel parameter or platform default
> > + * we can avoid reading registers so many times in vain
> > + */
> > + if (!i915.enable_fbc)
> > + return false;
> > +
> > if (!dev_priv->display.fbc_enabled)
> > return false;
>
> The correct state to check here is whether we have enabled fbc, not the
> module parameter which just rules whether we should turn it on.
> Look at making dev_priv->fbc.no_fbc_reason always correct instead.
Well we need to fix this all up anyway, since pretty much everything on
the software side of fbc is busted (locking, tracking, piles of rechecks
and other hilarious stuff).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
