On Thu, 31 Aug 2023, Matt Roper <matthew.d.roper@xxxxxxxxx> wrote: > On Thu, Aug 31, 2023 at 07:16:55PM +0300, Jani Nikula wrote: >> On Mon, 21 Aug 2023, Matt Roper <matthew.d.roper@xxxxxxxxx> 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. Thanks for the explanation. I'd ack just nuking the check. BR, Jani. > > > Matt > >> >> BR, >> Jani. >> >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center