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 <ramalinga...@intel.com> > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > --- > 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 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
