[Intel-gfx] [PATCH v5 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

[Matt Roper]

On Thu, Aug 31, 2023 at 07:16:55PM +0300, Jani Nikula wrote:
> On Mon, 21 Aug 2023, Matt Roper <matthew.d.roper at intel.com> wrote:
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index a408ec2d3958..4566c95da1ca 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -20,6 +20,7 @@
> >  #include "skl_scaler.h"
> >  #include "skl_universal_plane.h"
> >  #include "skl_watermark.h"
> > +#include "gt/intel_gt.h"
> >  #include "pxp/intel_pxp.h"
> >  
> >  static const u32 skl_plane_formats[] = {
> > @@ -2169,8 +2170,8 @@ static bool skl_plane_has_rc_ccs(struct drm_i915_private *i915,
> >  				 enum pipe pipe, enum plane_id plane_id)
> >  {
> >  	/* Wa_14017240301 */
> > -	if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > -	    IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > +	if (IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, STEP_B0) ||
> > +	    IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, STEP_B0))
> >  		return false;
> 
> This seems to be the only user of IS_GFX_GT_IP_STEP() under display/,
> and it kind of seems wrong to have display code check for GT
> versions. Is there a clean way to move this out of display?

If I remember correctly, this one literally is tied to the graphics IP
rather than the display IP.  There's something busted with how the
graphics GT is trying to generate compressed buffers that causes them to
not decompress properly in the display controller (although GT<->GT
compression/decompression is okay since both sides are broken in the
same way).  So the workaround is to not advertise our display planes as
having support for compressed buffers when the GT is A-step, because we
know they're going to show up in the wrong format.  That still allows
compression to be used for the non-display use cases, but avoids
possible display corruption.

Honestly the simplest solution might be to just go ahead and delete this
workaround since it's only relevant to pre-production hardware.  I know
our general policy has always been to hang on to workarounds for
pre-production steppings in the driver until the n+1 platform/IP is
pretty far along, but in this case it looks like our CI machines are
already on B0 GT stepping, and even if some internal people are still
working with older boards, this is still kind of a corner case that
probably won't impact most usage.


Matt

> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation