Re: [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Sat, Jan 27, 2018 at 02:49:15AM +0000, Dhinakaran Pandiyan wrote:
> There is no corresponding invalidate call before the buffer is written
> to, this results in screen freezing sometime after switching to console
> mode with PSR enabled. Invalidating the front buffer in the fbdev call
> backs won't work either as some of them are called in atomic contexts and
> {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.
> 
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index e9feffdea899..c12af1118647 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>  	if (!CAN_PSR(dev_priv))
>  		return;
>  
> +	if (origin == ORIGIN_DIRTYFB)
> +		return;
> +

I'd like Paulo to take a look here.

What I'm confused now is who (what fbt bit) is actually blocking PSR to work
on fbdev.

And what would be the risks of other corner cases or the risk of this
not getting psr re-enabled until next reboot...

>  	mutex_lock(&dev_priv->psr.lock);
>  	if (!dev_priv->psr.enabled) {
>  		mutex_unlock(&dev_priv->psr.lock);
> -- 
> 2.14.1
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx