Re: [PATCH] drm/i915: drrs_invalidate at flip schedule

Daniel Vetter
2015-05-18T08:17:58Z

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