Sorry for late response. I was away for longer.
Daniel,
As we have the intel_frontbuffer_flush, I have created the
intel_frontbuffer_invalidate.
This can be called from flip preparation notification to handle the
frontbuffer invalidation.
I will share the patches now.
On Monday 18 May 2015 01:50 PM, Daniel Vetter wrote:
On Fri, May 15, 2015 at 02:08:22AM +0530, Ramalingam C wrote:
After scheduling a flip for obj, we are supposed to invalidate the
drrs.
Action:
Adding a call to intel_edp_drrs_invalidate at
intel_frontbuffer_flip_prepare.
Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx>
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/intel_frontbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 57095f5..44387ed 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -244,6 +244,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev,
dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;
mutex_unlock(&dev_priv->fb_tracking.lock);
+ intel_edp_drrs_invalidate(dev, frontbuffer_bits);
Nope. The problem here is that drrs wants business, but the frontbuffer
tracking only gives you coherency signals (flush/invalidate). But for
business both flush and invalidate indicate that there's something going
on on the screen. Which means you _must_ uplock the display in both
drrs_flush and drrs_invalidate.
By applaying the upclocking only to the flip codepath you're only papering
over this bug in one specific case, but not for all the other paths where
frontbuffer rendering is possible.
-Daniel
intel_psr_single_frame_update(dev);
}
--
1.7.9.5
--
Thanks,
--Ram
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
