[Intel-gfx] [PATCH 1/2] drm/i915: Add display WA #1175 for planes ending close to right screen edge

[Imre Deak]

On Fri, Jan 12, 2018 at 03:01:59PM +0000, Chris Wilson wrote:
> Quoting Imre Deak (2018-01-12 14:54:36)
> > As described in the WA on GLK and CNL planes on the right edge of the
> > screen that have less than 4 pixels visible from the beginning of the
> > plane to the edge of the screen can cause FIFO underflow and display
> > corruption.
> > 
> > On GLK/CNL I could trigger the problem only if the plane was at the same
> > time also aligned to the top edge of the screen (after clipping) and
> > there were exactly 2 pixels visible from the start of the plane to the
> > right edge of the screen (so couldn't trigger it with 1 or 3 pixels
> > visible). Nevertheless, to be sure, I also applied the WA for these cases.
> > 
> > I also couldn't see any problem with the cursor plane and later Art
> > confirmed that it's not affected, so the WA is applied only for the
> > other plane types.
> > 
> > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 28 ++++++++++++++++++++++++----
> >  drivers/gpu/drm/i915/intel_drv.h     |  3 ++-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  2 +-
> >  3 files changed, 27 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 221e3a183d36..3d931b652795 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2917,14 +2917,19 @@ static bool skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state
> >         return true;
> >  }
> >  
> > -static int skl_check_main_surface(struct intel_plane_state *plane_state)
> > +static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
> > +                                 struct intel_plane_state *plane_state)
> >  {
> > +       struct drm_i915_private *dev_priv =
> > +               to_i915(plane_state->base.plane->dev);
> >         const struct drm_framebuffer *fb = plane_state->base.fb;
> >         unsigned int rotation = plane_state->base.rotation;
> >         int x = plane_state->base.src.x1 >> 16;
> >         int y = plane_state->base.src.y1 >> 16;
> >         int w = drm_rect_width(&plane_state->base.src) >> 16;
> >         int h = drm_rect_height(&plane_state->base.src) >> 16;
> > +       int dst_x = plane_state->base.dst.x1;
> > +       int pipe_src_w = crtc_state->pipe_src_w;
> >         int max_width = skl_max_plane_width(fb, 0, rotation);
> >         int max_height = 4096;
> >         u32 alignment, offset, aux_offset = plane_state->aux.offset;
> > @@ -2935,6 +2940,20 @@ static int skl_check_main_surface(struct intel_plane_state *plane_state)
> >                 return -EINVAL;
> >         }
> >  
> > +       /*
> > +        * Display WA #1175: cnl,glk
> > +        * Planes other than the cursor may cause FIFO underflow and display
> > +        * corruption if starting less than 4 pixels from the right edge of
> > +        * the screen.
> > +        */
> > +       if ((IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> > +           dst_x > pipe_src_w - 4) {
> > +               DRM_DEBUG_KMS("requested plane X start position %d invalid (valid range %d-%d)\n",
> > +                             dst_x,
> > +                             0, pipe_src_w - 4);
> 
> You are rejecting user input, so this should be DRM_DEBUG() (or whatever
> the future user channel will be).

What's the rational for a user channel? Not having to build the rest of
debugging stuff, or a simpler user interface?

The rest of places failing due to user input on this path also use
DRM_DEBUG_KMS(), so we could also convert all as a follow-up.

--Imre