All of 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 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.