Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
To: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"stefanr@s5r6.in-berlin.de" <stefanr@s5r6.in-berlin.de>,
	"stevenhoneyman@gmail.com" <stevenhoneyman@gmail.com>
Subject: Re: drm/i915/fbc: disable FBC on FIFO underruns
Date: Fri, 12 Aug 2016 23:24:59 +0000	[thread overview]
Message-ID: <1471045162.10941.68.camel@dk-H97M-D3H> (raw)
In-Reply-To: <1465607883-8533-1-git-send-email-paulo.r.zanoni@intel.com>

On Fri, 2016-06-10 at 22:18 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black screens.
> 

Do we know why we get black screens in this scenario?

> We recently tried to enable FBC on Haswell and got reports of a system
> that would hang after some hours of uptime, and the first bad commit
> was the one that enabled FBC. We also observed that this system had
> FIFO underrun error messages on its dmesg. Although we don't have any
> evidence that fixing the underruns would solve the bug and make FBC
> work properly on this machine, IMHO it's better if we minimize the
> amount of possible problems by just giving up FBC whenever we detect
> an underrun.
> 
> v2: new version, different implementation and commit message.
> 
> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Lyude <cpaul@redhat.com>
> Cc: Steven Honeyman <stevenhoneyman@gmail.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h            |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h           |  1 +
>  drivers/gpu/drm/i915/intel_fbc.c           | 53 ++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 ++
>  4 files changed, 59 insertions(+)
> 
> 
> Since my test machines don't produce FIFO underrun errors, I tested this by
> creating a debugfs file that just calls intel_fbc_handle_fifo_underrun(). I'd
> appreciate some Tested-by tags, if possible.
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20a676d..18b4257 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -908,6 +908,9 @@ struct intel_fbc {
>  	bool enabled;
>  	bool active;
>  
> +	bool underrun_detected;
> +	struct work_struct underrun_work;
> +
>  	struct intel_fbc_state_cache {
>  		struct {
>  			unsigned int mode_flags;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index ebe7b34..7bf97b1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1436,6 +1436,7 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>  		     unsigned int frontbuffer_bits, enum fb_op_origin origin);
>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> +void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv);
>  
>  /* intel_hdmi.c */
>  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port port);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
> index d268f76..2363bff 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -755,6 +755,13 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>  	struct intel_fbc *fbc = &dev_priv->fbc;
>  	struct intel_fbc_state_cache *cache = &fbc->state_cache;
>  
> +	/* We don't need to use a state cache here since this information is
> +	 * global for every CRTC. */
> +	if (fbc->underrun_detected) {
> +		fbc->no_fbc_reason = "underrun detected";
> +		return false;
> +	}
> +
>  	if (!cache->plane.visible) {
>  		fbc->no_fbc_reason = "primary plane not visible";
>  		return false;
> @@ -1195,6 +1202,51 @@ void intel_fbc_global_disable(struct drm_i915_private *dev_priv)
>  	cancel_work_sync(&fbc->work.work);
>  }
>  
> +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> +{
> +	struct drm_i915_private *dev_priv =
> +		container_of(work, struct drm_i915_private, fbc.underrun_work);
> +	struct intel_fbc *fbc = &dev_priv->fbc;
> +
> +	mutex_lock(&fbc->lock);
> +
> +	/* Maybe we were scheduled twice. */
> +	if (fbc->underrun_detected)
> +		goto out;
> +
> +	DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
> +	fbc->underrun_detected = true;
> +
> +	intel_fbc_deactivate(dev_priv);
> +out:
> +	mutex_unlock(&fbc->lock);
> +}
> +
> +/**
> + * intel_fbc_handle_fifo_underrun - disable FBC when we get a FIFO underrun
> + * @dev_priv: i915 device instance
> + *
> + * Without FBC, most underruns are harmless and don't really cause too many
> + * problems, except for an annoying message on dmesg. With FBC, underruns can
> + * become black screens or even worse, especially when paired with bad
> + * watermarks. So in order for us to be on the safe side, completely disable FBC
> + * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
> + * already suggests that watermarks may be bad, so try to be as safe as
> + * possible.
> + */
> +void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv)
> +{
> +	struct intel_fbc *fbc = &dev_priv->fbc;
> +
> +	if (!fbc_supported(dev_priv))
> +		return;
> +

Should we bail out if fbc is not enabled?
Also, can we just disable fbc if we see an underrun instead of using a
new flag to prevent activation?

> +	if (fbc->underrun_detected)
> +		return;
> +
> +	schedule_work(&fbc->underrun_work);
> +}
> +
>  /**
>   * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
>   * @dev_priv: i915 device instance
> @@ -1250,6 +1302,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
>  	enum pipe pipe;
>  
>  	INIT_WORK(&fbc->work.work, intel_fbc_work_fn);
> +	INIT_WORK(&fbc->underrun_work, intel_fbc_underrun_work_fn);
>  	mutex_init(&fbc->lock);
>  	fbc->enabled = false;
>  	fbc->active = false;
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index 9be839a..9d43cbd 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -370,6 +370,8 @@ void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
>  	if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false))
>  		DRM_ERROR("CPU pipe %c FIFO underrun\n",
>  			  pipe_name(pipe));
> +
> +	intel_fbc_handle_fifo_underrun(dev_priv);
>  }
>  

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-08-12 23:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-11  1:18 [PATCH] drm/i915/fbc: disable FBC on FIFO underruns Paulo Zanoni
2016-06-11  6:56 ` ✗ Ro.CI.BAT: warning for " Patchwork
2016-06-13 11:47 ` [PATCH] " Stefan Richter
2016-06-13 14:33   ` Zanoni, Paulo R
2016-06-15 12:19     ` Stefan Richter
2016-08-12 23:24 ` Pandiyan, Dhinakaran [this message]
2016-08-13  9:05   ` Chris Wilson
2016-08-15 20:49     ` Zanoni, Paulo R
2016-08-15 22:36       ` [PATCH] " Paulo Zanoni
2016-09-02  5:58         ` Pandiyan, Dhinakaran
2016-09-02 14:45           ` Zanoni, Paulo R
2016-09-12 20:02             ` Paulo Zanoni
2016-09-12 20:25               ` Chris Wilson
2016-09-12 21:25                 ` Zanoni, Paulo R
2016-09-13 13:38                   ` Paulo Zanoni
2016-09-13 13:56                     ` Chris Wilson
2016-09-13 17:07                     ` Pandiyan, Dhinakaran
2016-08-16  5:57 ` ✗ Ro.CI.BAT: failure for drm/i915/fbc: disable FBC on FIFO underruns (rev2) Patchwork
2016-09-12 20:54 ` ✓ Fi.CI.BAT: success for drm/i915/fbc: disable FBC on FIFO underruns (rev3) Patchwork
2016-09-13 14:19 ` ✗ Fi.CI.BAT: warning for drm/i915/fbc: disable FBC on FIFO underruns (rev4) 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=1471045162.10941.68.camel@dk-H97M-D3H \
    --to=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=stevenhoneyman@gmail.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