All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tarun Vyas <tarun.vyas@intel.com>, intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, dhinakaran.pandiyan@intel.com,
	rodrigo.vivi@intel.com
Subject: Re: [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
Date: Mon, 14 May 2018 22:16:38 +0100	[thread overview]
Message-ID: <152633259830.18532.13089667925706543216@mail.alporthouse.com> (raw)
In-Reply-To: <20180514204922.82073-3-tarun.vyas@intel.com>

Quoting Tarun Vyas (2018-05-14 21:49:22)
> 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 supported and active
> on the current pipe) before reading the PIPEDSL, b/c if we haven't
> fully exited PSR, then checking for vblank evasion isn't actually
> applicable.
> 
> This scenario applies to a configuration with an additional pipe,
> as of now
> 
> Signed-off-by: Tarun Vyas <tarun.vyas@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index ee23613f9fd4..481d310e5c3b 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -107,14 +107,17 @@ 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;
>  
>         if (WARN_ON(drm_crtc_vblank_get(&crtc->base)))
>                 return;
>  
> +       if(new_crtc_state->has_psr && dev_priv->psr.active)
> +               psr_wait_for_idle(dev_priv);
> +
> +       local_irq_disable();

Pop quiz, does intel_pipe_update_finish() unconditionally assume it is
called with irqs disabled?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-14 21:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 20:49 [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused Tarun Vyas
2018-05-14 20:49 ` [PATCH 2/2] drm/i915: Un-statify psr_wait_for_idle Tarun Vyas
2018-05-14 20:49 ` [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion Tarun Vyas
2018-05-14 21:16   ` Chris Wilson [this message]
2018-05-15 19:38     ` Tarun Vyas
2018-05-15  3:16   ` kbuild test robot
2018-06-19 21:27   ` Dhinakaran Pandiyan
2018-06-19 21:54     ` Dhinakaran Pandiyan
2018-06-19 21:59       ` Tarun Vyas
2018-06-19 23:11         ` Dhinakaran Pandiyan
2018-06-21 22:43         ` Tarun Vyas
2018-05-14 21:15 ` [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused Chris Wilson
2018-05-14 22:00   ` Tarun Vyas
2018-05-17 20:35     ` Tarun Vyas
2018-05-14 21:35 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2] drm/i915: Wait for PSR exit before checking for vblank evasion (rev2) Patchwork
2018-05-14 21:36 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-14 21:53 ` ✗ Fi.CI.BAT: failure " 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=152633259830.18532.13089667925706543216@mail.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --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.