[Intel-gfx] [PATCH] Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709"

[Joonas Lahtinen]

Quoting Matt Roper (2022-08-27 00:02:33)
> This reverts commit ca6920811aa5428270dd78af0a7a36b10119065a.
> 
> The intent of Wa_14015141709 was to inform us that userspace can no
> longer control object-level preemption as it has on past platforms
> (i.e., by twiddling register bit CS_CHICKEN1[0]).  The description of
> the workaround in the spec wasn't terribly well-written, and when we
> requested clarification from the hardware teams we were told that on the
> kernel side we should also probably stop setting
> FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the
> hardware to honor the settings in per-context register CS_CHICKEN1.  It
> turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a
> mistake; even though CS_CHICKEN1[0] is non-operational and useless to
> userspace, there are other bits in the register that do still work and
> might need to be adjusted by userspace in the future (e.g., to implement
> other workarounds that show up).  If we don't set
> FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would
> not take effect.

Here we should be referencing Mesa/Compute runtime/etc. patches that
intend to use these other bits.

This is to ensure that they're actually aware of the hardware changes
ongoing and we end up with fully functional stack and not kernel doing
something other than the userspace attempts to do.

> This miscommunication came to light because another workaround
> (Wa_16013994831) has now shown up that requires userspace to adjust the
> value of CS_CHICKEN[10] in certain circumstances.  To ensure userspace's
> updates to this chicken bit are handled properly by the hardware, we
> need to make sure that FF_SLICE_CS_CHICKEN1[14] is once again set by the
> kernel.
> 
> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>

Not too many Cc:s for a patch that impacts uAPI. Even the original patch
being reverted definitely should have Cc:d mesa and some mesa devs.

> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
>  drivers/gpu/drm/i915/i915_drv.h             | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3cdb8294e13f..69a0c6a74474 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2389,7 +2389,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
>                              FF_DOP_CLOCK_GATE_DISABLE);
>         }
>  
> -       if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
> +       if (IS_GRAPHICS_VER(i915, 9, 12)) {
>                 /* FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */

According to the commit description, this is not the W/A being supported
anymore by the whitelisting. Even if it's the same register we're talking about
different bits and different reasons.

We should clearly indicate that.

Can we have a followup patch where the reasoning is explained more
clearly and the userspace side changes are being referenced and at least
some userspace folks Cc'd?

Regards, Joonas

>                 wa_masked_en(wal,
>                              GEN7_FF_SLICE_CS_CHICKEN1,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b00ef3626db..d6a1ab6f65de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1352,9 +1352,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_GUC_DEPRIVILEGE(dev_priv) \
>         (INTEL_INFO(dev_priv)->has_guc_deprivilege)
>  
> -#define HAS_PERCTX_PREEMPT_CTRL(i915) \
> -       ((GRAPHICS_VER(i915) >= 9) &&  GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
> -
>  #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
>                                               IS_ALDERLAKE_S(dev_priv))
>  
> -- 
> 2.37.2
>