public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/i915: More cautious with pch fifo underruns
Date: Wed, 26 Nov 2014 18:49:46 +0200	[thread overview]
Message-ID: <20141126164946.GP10649@intel.com> (raw)
In-Reply-To: <CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com>

On Wed, Nov 26, 2014 at 01:37:07PM -0200, Paulo Zanoni wrote:
> 2014-11-24 14:02 GMT-02:00 Daniel Vetter <daniel.vetter@ffwll.ch>:
> > Apparently PCH fifo underruns are tricky, we have plenty reports that
> > we see the occasional underrun (especially at boot-up).
> >
> > So for a change let's see what happens when we don't re-enable pch
> > fifo underrun reporting when the pipe is disabled.
> 
> Does that mean you don't really know if this patch is going to fix something?
> 
> I see what this patch does, but I don't really see what is its
> benefit, besides "we'll get less bug reports". Is there any reason why
> the underruns are expected to happen at this time?

IIRC the conclusion I came to when looking at my IVB was that the underruns
were expected when fdi was disabled but the pch transcoder was enabled,
or maybe it was between pipe disable and pch transcoder disable. Either
or both would make sense to me.

But we already have the underrun reporting disabled around those parts,
so my memory might be failing me here. Also my IVB doesn't seem to
trigger these anymore. Not sure what exactly has changed.

Or maybe I used to get them in the crtc_enable path. We do enable the
underrun reporting already before fdi or pch transcoder are enabled.
Although we do the enable in order, so if my memory about the conditions
is correct we shouldn't get any there either.

> 
> Please explain a little more.
> 
> > This means that the
> > kernel can't catch pch fifo underruns when they happen (except when
> > all pipes are on on the pch). But we'll still catch underruns when
> > disabling the pipe again.
> 
> Are you sure the sentences above are correct?
> 
> 
> > So not a terrible reduction in test
> > coverage.
> 
> Yeah, I agree, but please provide a nice reason for it :)
> 
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=85898
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=86233
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=86478
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 320bf4c78c8c..a4106049e158 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4501,7 +4501,6 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
> >                 ironlake_fdi_disable(crtc);
> >
> >                 ironlake_disable_pch_transcoder(dev_priv, pipe);
> > -               intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
> >
> >                 if (HAS_PCH_CPT(dev)) {
> >                         /* disable TRANS_DP_CTL */
> > @@ -4572,8 +4571,6 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
> >
> >         if (intel_crtc->config.has_pch_encoder) {
> >                 lpt_disable_pch_transcoder(dev_priv);
> > -               intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> > -                                                     true);
> >                 intel_ddi_fdi_disable(crtc);
> >         }
> >
> > --
> > 2.1.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Paulo Zanoni
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-11-26 16:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 16:02 [PATCH] drm/i915: More cautious with pch fifo underruns Daniel Vetter
2014-11-25  3:53 ` shuang.he
2014-11-25  8:38 ` Daniel Vetter
2014-11-26 15:37 ` Paulo Zanoni
2014-11-26 16:49   ` Ville Syrjälä [this message]
2014-11-26 18:17   ` Daniel Vetter
2014-12-01 13:41     ` Paulo Zanoni
2014-12-01 16:36       ` Daniel Vetter
2014-12-01 17:04         ` Paulo Zanoni
2014-12-01 17:27           ` Daniel Vetter
2014-12-02 13:22             ` Jani Nikula

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=20141126164946.GP10649@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@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