[Intel-gfx] [PATCH v3] drm/i915/display: Record the plane update times for debugging

[Chris Wilson]

Quoting Ville Syrjälä (2020-12-03 12:45:43)
> On Wed, Dec 02, 2020 at 09:28:09PM +0000, Chris Wilson wrote:
> > Since we try and estimate how long we require to update the registers to
> > perform a plane update, it is of vital importance that we measure the
> > distribution of plane updates to better guide our estimate. If we
> > underestimate how long it takes to perform the plane update, we may
> > slip into the next scanout frame causing a tear. If we overestimate, we
> > may unnecessarily delay the update to the next frame, causing visible
> > jitter.
> > 
> > Replace the warning that we exceed some arbitrary threshold for the
> > vblank update with a histogram for debugfs.
> > 
> > v2: Add a per-crtc debugfs entry so that the information is easier to
> > extract when testing individual CRTC, and so that it can be reset before
> > a test.
> > 
> > v3: Flip the graph on its side; creates space to label the time axis.
> > 
> > Updates: 4684
> >        |
> >    1us |
> >        |
> >    4us |********
> >        |**********
> >   16us |***********
> >        |*****
> >   66us |
> >        |
> >  262us |
> >        |
> >    1ms |
> >        |
> >    4ms |
> >        |
> >   17ms |
> >        |
> 
> Going that high feels a bit overkill to me. I'd be satisified
> with an upper limit of <1ms or something.
 
I thought 16ms was overkill, but looking at the results, we do get some
delays >1ms (but not raising an error for missing the start of vblank).

I capped it there just in case there is a bug where we wait for a whole
vblank, which is about as severe a bug as one might expect.
-Chris