Re: [PATCH 1/4] drm/i915: fix FBC frontbuffer tracking flushing code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni <przanoni@xxxxxxxxx> wrote:
From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>

Due to the way busy_bits was handled, we were not doing any flushes if
we didn't previously get an invalidate. Since it's possible to get
flushes without an invalidate first, remove the busy_bits early
return.

So now that we don't have the busy_bits guard anymore we'll need the
origin check for the GTT tracking (we were not doing anything on GTT
flushes due to the GTT check at invalidate()).

As a last detail, since we can get multiple consecutive flushes,
disable FBC before updating it, otherwise intel_fbc_update() will just
keep FBC enabled instead of restarting it.

Notice that this does not fix any of the current IGT tests due to the
fact that we still have a few intel_fbc() calls at points where we
also have the frontbuffer tracking calls: we didn't fully convert to
frontbuffer tracking yet. Once we remove those calls and start relying
only on the frontbuffer tracking infrastructure we'll need this patch.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>
---
 drivers/gpu/drm/i915/intel_drv.h         |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c         | 13 +++++++------
 drivers/gpu/drm/i915/intel_frontbuffer.c |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f4abce1..2437666 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1240,7 +1240,7 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
                          unsigned int frontbuffer_bits,
                          enum fb_op_origin origin);
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
-                    unsigned int frontbuffer_bits);
+                    unsigned int frontbuffer_bits, enum fb_op_origin origin);
 const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index c271af7..1f97fb5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -884,22 +884,23 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
 }

 void intel_fbc_flush(struct drm_i915_private *dev_priv,
-                    unsigned int frontbuffer_bits)
+                    unsigned int frontbuffer_bits, enum fb_op_origin origin)
 {
        if (!dev_priv->fbc.enable_fbc)
                return;

-       mutex_lock(&dev_priv->fbc.lock);
+       if (origin == ORIGIN_GTT)
+               return;

-       if (!dev_priv->fbc.busy_bits)
-               goto out;
+       mutex_lock(&dev_priv->fbc.lock);

        dev_priv->fbc.busy_bits &= ~frontbuffer_bits;

-       if (!dev_priv->fbc.busy_bits)
+       if (!dev_priv->fbc.busy_bits) {
+               __intel_fbc_disable(dev_priv);
                __intel_fbc_update(dev_priv);

are we going to kill fbc_update for good? ;)

But yes, we need to force the disable on flush so this is good.
I'd just add in a separated patch, but anyway feel free to use

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
 
+       }

-out:
        mutex_unlock(&dev_priv->fbc.lock);
 }

diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 777b1d3..ac85357 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -129,7 +129,7 @@ static void intel_frontbuffer_flush(struct drm_device *dev,

        intel_edp_drrs_flush(dev, frontbuffer_bits);
        intel_psr_flush(dev, frontbuffer_bits, origin);
-       intel_fbc_flush(dev_priv, frontbuffer_bits);
+       intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
 }

 /**
--
2.1.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux