All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915/psr: Rewrite comments in intel_psr_wait_for_idle()
Date: Fri, 24 Aug 2018 16:19:33 -0700	[thread overview]
Message-ID: <20180824231933.GJ6432@intel.com> (raw)
In-Reply-To: <20180824230844.12428-2-dhinakaran.pandiyan@intel.com>

On Fri, Aug 24, 2018 at 04:08:44PM -0700, Dhinakaran Pandiyan wrote:
> Added bspec reference, aligned text and documented the function.
> 
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> ---
>  drivers/gpu/drm/i915/intel_psr.c | 28 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index 2cb931f3019b..aee64aee18fe 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -766,6 +766,16 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>  	cancel_work_sync(&dev_priv->psr.work);
>  }
>  
> +/**
> + * intel_psr_wait_for_idle - wait for PSR1 to idle
> + * @new_crtc_state: new CRTC state
> + * @out_value: PSR status in case of failure
> + *
> + * This function is expected to be called from pipe_update_start() where it is
> + * not expected to race with PSR enable or disable.
> + *
> + * Returns: 0 on success or -ETIMEOUT if PSR status does not idle.
> + */
>  int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
>  			    u32 *out_value)
>  {
> @@ -775,25 +785,15 @@ int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
>  	if (!dev_priv->psr.enabled || !new_crtc_state->has_psr)
>  		return 0;
>  
> -	/*
> -	 * The sole user right now is intel_pipe_update_start(),
> -	 * which won't race with psr_enable/disable, which is
> -	 * where psr2_enabled is written to. So, we don't need
> -	 * to acquire the psr.lock. More importantly, we want the
> -	 * latency inside intel_pipe_update_start() to be as low
> -	 * as possible, so no need to acquire psr.lock when it is
> -	 * not needed and will induce latencies in the atomic
> -	 * update path.
> -	 */
> -
>  	/* FIXME: Update this for PSR2 if we need to wait for idle */
>  	if (READ_ONCE(dev_priv->psr.psr2_enabled))
>  		return 0;
>  
>  	/*
> -	 * Max time for PSR to idle = Inverse of the refresh rate +
> -	 * 6 ms of exit training time + 1.5 ms of aux channel
> -	 * handshake. 50 msec is defesive enough to cover everything.
> +	 * From bspec: Panel Self Refresh (BDW+)
> +	 * Max. time for PSR to idle = Inverse of the refresh rate + 6 ms of
> +	 * exit training time + 1.5 ms of aux channel handshake. 50 ms is
> +	 * defensive enough to cover everything.
>  	 */
>  
>  	return __intel_wait_for_register(dev_priv, EDP_PSR_STATUS,
> -- 
> 2.17.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-08-24 23:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-24 23:08 [PATCH 1/2] drm/i915/psr: Remove wait_for_idle() for PSR2 Dhinakaran Pandiyan
2018-08-24 23:08 ` [PATCH 2/2] drm/i915/psr: Rewrite comments in intel_psr_wait_for_idle() Dhinakaran Pandiyan
2018-08-24 23:19   ` Rodrigo Vivi [this message]
2018-08-24 23:18 ` [PATCH 1/2] drm/i915/psr: Remove wait_for_idle() for PSR2 Rodrigo Vivi
2018-08-24 23:31 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
2018-08-25  0:20 ` ✓ Fi.CI.IGT: " Patchwork

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=20180824231933.GJ6432@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.