All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
To: Tarun Vyas <tarun.vyas@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, rodrigo.vivi@intel.com
Subject: Re: [PATCH v8 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion
Date: Fri, 29 Jun 2018 16:26:14 -0700	[thread overview]
Message-ID: <1530314774.25977.5.camel@intel.com> (raw)
In-Reply-To: <20180627200250.1515-2-tarun.vyas@intel.com>

On Wed, 2018-06-27 at 13:02 -0700, Tarun Vyas wrote:
> The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then
> the pipe_update_start call schedules itself out to check back later.
> 
> On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
> lags w.r.t core kernel code, hot plugging an external display
> triggers
> tons of "potential atomic update errors" in the dmesg, on *pipe A*. A
> closer analysis reveals that we try to read the scanline 3 times and
> eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL
> stuck @ 1599. This issue is not seen on upstream kernels, b/c for
> *some*
> reason we loop inside intel_pipe_update start for ~2+ msec which in
> this
> case is more than enough to exit PSR fully, hence an *unstuck*
> PIPEDSL
> counter, hence no error. On the other hand, the ChromeOS kernel
> spends
> ~1.1 msec looping inside intel_pipe_update_start and hence errors out
> b/c the source is still in PSR.
> 
> Regardless, we should wait for PSR exit (if PSR is disabled, we incur
> a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't
> fully exited PSR, then checking for vblank evasion isn't actually
> applicable.
> 
> v4: Comment explaining psr_wait after enabling VBL interrupts (DK)
> 
> v5: CAN_PSR() to handle platforms that don't support PSR.
> 
> v6: Handle local_irq_disable on early return (Chris)
 
Series Reviewed-by: Dhinakaran Pandiyan
<dhinakaran.pandiyan@intel.com>

Daniel's questions were addressed over IRC, I'll push this version if
they aren't any other concerns.

-DK
> 
> Signed-off-by: Tarun Vyas <tarun.vyas@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 344c0e709b19..4990d6e84ddf 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -107,13 +107,21 @@ void intel_pipe_update_start(const struct
> intel_crtc_state *new_crtc_state)
>  						      VBLANK_EVASION
> _TIME_US);
>  	max = vblank_start - 1;
>  
> -	local_irq_disable();
> -
>  	if (min <= 0 || max <= 0)
> -		return;
> +		goto irq_disable;
>  
>  	if (WARN_ON(drm_crtc_vblank_get(&crtc->base)))
> -		return;
> +		goto irq_disable;
> +
> +	/*
> +	 * Wait for psr to idle out after enabling the VBL
> interrupts
> +	 * VBL interrupts will start the PSR exit and prevent a PSR
> +	 * re-entry as well.
> +	 */
> +	if (CAN_PSR(dev_priv) && intel_psr_wait_for_idle(dev_priv))
> +		DRM_ERROR("PSR idle timed out, atomic update may
> fail\n");
> +
> +	local_irq_disable();
>  
>  	crtc->debug.min_vbl = min;
>  	crtc->debug.max_vbl = max;
> @@ -171,6 +179,10 @@ void intel_pipe_update_start(const struct
> intel_crtc_state *new_crtc_state)
>  	crtc->debug.start_vbl_count =
> intel_crtc_get_vblank_counter(crtc);
>  
>  	trace_i915_pipe_update_vblank_evaded(crtc);
> +	return;
> +
> +irq_disable:
> +	local_irq_disable();
>  }
>  
>  /**
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-06-29 23:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 20:02 [PATCH v8 1/2] drm/i915/psr: Lockless version of psr_wait_for_idle Tarun Vyas
2018-06-27 20:02 ` [PATCH v8 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion Tarun Vyas
2018-06-29 23:26   ` Dhinakaran Pandiyan [this message]
2018-07-02 18:40     ` Dhinakaran Pandiyan
2018-06-27 20:53 ` ✓ Fi.CI.BAT: success for series starting with [v8,1/2] drm/i915/psr: Lockless version of psr_wait_for_idle Patchwork
2018-06-28  1:41 ` ✓ 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=1530314774.25977.5.camel@intel.com \
    --to=dhinakaran.pandiyan@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tarun.vyas@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 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.