Re: [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
Date: Fri, 30 Oct 2015 16:42:26 +0100	[thread overview]
Message-ID: <20151030154226.GD16848@phenom.ffwll.local> (raw)
In-Reply-To: <20151029212128.GY4437@intel.com>

On Thu, Oct 29, 2015 at 11:21:28PM +0200, Ville Syrjälä wrote:
> On Thu, Oct 29, 2015 at 05:57:57PM -0200, Paulo Zanoni wrote:
> > 2015-10-29 17:25 GMT-02:00  <ville.syrjala@linux.intel.com>:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > We get spurious PCH FIFO underruns if we enable the reporting too soon
> > > after enabling the crtc. Move it to be the last step, after the encoder
> > > enable. Additionally we need an extra vblank wait, otherwise we still
> > > get the underruns. Presumably the pipe/fdi isn't yet fully up and running
> > > otherwise.
> > >
> > > For symmetry, disable the PCH underrun reporting as the first thing,
> > > just before encoder disable, when shutting down the crtc.
> > 
> > Is there any place that describes where/when a FIFO underrun is
> > expected and where/when one is an actual problem that needs to be
> > solved? How do we know the underruns avoided by these patch are not a
> > signal of real bugs?
> 
> Can't be 100% sure since its not documented anywhere. But we've been
> getting these since forever now and stuff still works (more or less at
> least), so I'm inclined to say we don't have to care about them. Also
> in these case we only get PCH FIFO underruns and no CPU pipe
> underruns, so I'm tempted to say it's not that serious.
> 
> IIRC I once tracked some of these down to having the FDI PLL enabled
> with FDI RX/TX disabled. Or something like that, but don't quote me
> on that since my memory might be failing here. Obviously that can't
> explain it all since I still need the vblank wait to eliminate them.
> Anyway, this time I didn't try to narrow it down too much. Instead
> my aim was more to reliably eliminate them without permamently disabling
> the underrun detection.
> 
> In any case, we can't get the bat stuff really working until we get
> the results to be stable, and these underruns are one big obstacle
> to that.

Agreed with Ville here, these are old platforms and we want stable BAT
results first. On gen9+ we should try a bit harder, or at least make a
note in JIRA that we need to look into this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx