[Intel-gfx] [PATCH] drm/i915: drrs_invalidate at flip schedule

[Daniel Vetter]

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 at intel.com>
> Signed-off-by: Chris Wilson <chris at 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