public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
To: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 1/2] drm/i915: PSR: Let's rely more on frontbuffer tracking.
Date: Wed, 18 Nov 2015 19:27:48 +0000	[thread overview]
Message-ID: <1447874867.2913.32.camel@intel.com> (raw)
In-Reply-To: <1447874472-1806-1-git-send-email-rodrigo.vivi@intel.com>

Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu:
> The ultimate goal here is to remove the dependency we
> currently have on audio driver power to get PSR working.
> Since with audio driver runtime PM disabled the Hardware tracking
> believes graphics is fully active and prevent PSR Entry, or
> in other words continuously exit PSR.
> 
> So, the idea is to transfer the PSR exit responsability
> from the HW tracking to the SW tracking (frontbuffer tracking),
> who is really mature right now.
> 
> However with LPSP masked out there might be cases where we could
> miss exit from HW tracking since it can be relying on this,
> like a specific case reported at our mailing list who
> user reported he would miss screen updates if scrolling firefox
> in a Gnome environment when i915 runtimepm was enabled.
> 
> So before masking out LPSP again to make us independent from
> the audio driver we need to make sure that all our cases
> are coverred from the frontbuffer tracking perspective,
> where the flush means invalidate and flush.
> 
> Without this patch for HSW, BDW and SKL we just do the
> invalidate part when the flush wasn't originated by a page flip
> because we were trusting the HW tracking for the flip case.
> 
> So let's rely more on frontbuffer tracking and do the
> invalidation regardless the origin as expected for all platforms.
> 
> v2: Improve commit message as suggested by Paulo.
> 
> v3: Another attempt to let commit message more clear.
> 
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
s/Cc/Reviewed-by/

> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 22 +++-------------------
>  1 file changed, 3 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index e5b3fce..b0e343c 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -711,25 +711,9 @@ void intel_psr_flush(struct drm_device *dev,
>  	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
>  	dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
>  
> -	if (HAS_DDI(dev)) {
> -		/*
> -		 * By definition every flush should mean invalidate
> + flush,
> -		 * however on core platforms let's minimize the
> -		 * disable/re-enable so we can avoid the invalidate
> when flip
> -		 * originated the flush.
> -		 */
> -		if (frontbuffer_bits && origin != ORIGIN_FLIP)
> -			intel_psr_exit(dev);
> -	} else {
> -		/*
> -		 * On Valleyview and Cherryview we don't use
> hardware tracking
> -		 * so any plane updates or cursor moves don't result
> in a PSR
> -		 * invalidating. Which means we need to manually
> fake this in
> -		 * software for all flushes.
> -		 */
> -		if (frontbuffer_bits)
> -			intel_psr_exit(dev);
> -	}
> +	/* By definition flush = invalidate + flush */
> +	if (frontbuffer_bits)
> +		intel_psr_exit(dev);
>  
>  	if (!dev_priv->psr.active && !dev_priv-
> >psr.busy_frontbuffer_bits)
>  		schedule_delayed_work(&dev_priv->psr.work,
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-11-18 19:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 21:19 [PATCH 0/4] PSR general improvements and stabilization Rodrigo Vivi
2015-11-11 21:19 ` [PATCH 1/4] drm/i915: Force PSR exit when IRQ_HPD is detected on eDP Rodrigo Vivi
2015-11-16 16:55   ` Ville Syrjälä
2015-11-18 19:19     ` [PATCH] " Rodrigo Vivi
2015-11-23 21:29       ` Rodrigo Vivi
2015-12-01 18:56       ` Ville Syrjälä
2015-12-01 19:44         ` Vivi, Rodrigo
2015-12-02  9:42           ` Ville Syrjälä
2015-12-02 17:29             ` Vivi, Rodrigo
2015-11-11 21:19 ` [PATCH 2/4] drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink Rodrigo Vivi
2015-11-12 22:46   ` [PATCH] " Rodrigo Vivi
2015-11-16 16:44     ` Paulo Zanoni
2015-11-11 21:20 ` [PATCH 3/4] drm/i915: PSR: Let's rely more on frontbuffer tracking Rodrigo Vivi
2015-11-14  0:56   ` [PATCH] " Rodrigo Vivi
2015-11-16 18:57     ` Paulo Zanoni
2015-11-16 20:39       ` Vivi, Rodrigo
2015-11-18 19:21       ` [PATCH 1/2] " Rodrigo Vivi
2015-11-18 19:27         ` Zanoni, Paulo R [this message]
2015-11-19 11:16           ` Jani Nikula
2015-11-19 11:24             ` Zanoni, Paulo R
2015-11-19 12:03               ` Damien Lespiau
2015-11-11 21:20 ` [PATCH 4/4] drm/i915: PSR: Mask LPSP hw tracking back again Rodrigo Vivi
2015-11-16 19:27   ` Paulo Zanoni
2015-11-18  0:01     ` Vivi, Rodrigo
2015-11-18 19:21     ` [PATCH 2/2] " Rodrigo Vivi
2015-11-18 19:29       ` Zanoni, Paulo R
2015-11-18 21:49     ` Rodrigo Vivi
2015-11-23 21:52       ` Rodrigo Vivi
2015-11-24 12:29         ` Daniel Vetter
2015-11-24 17:12 ` [PATCH 0/4] PSR general improvements and stabilization Daniel Stone
2015-11-24 20:53   ` Vivi, Rodrigo
2015-11-25  8:42     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1447874867.2913.32.camel@intel.com \
    --to=paulo.r.zanoni@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox