[Intel-gfx] [PATCH] drm/i915/wopcm: Handle pre-programmed WOPCM registers
Teres Alexis, Alan Previn
alan.previn.teres.alexis at intel.com
Thu Jan 20 18:13:47 UTC 2022
Just one nit below, (assuming that igt CI failure isnt related - kms flip not completing)
Reviewed-by Alan Previn <alan.previn.teres.alexis at intel.com>
-----Original Message-----
From: Ceraolo Spurio, Daniele <daniele.ceraolospurio at intel.com>
Sent: Friday, January 14, 2022 11:33 AM
To: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org; Ceraolo Spurio, Daniele <daniele.ceraolospurio at intel.com>; Summers, Stuart <stuart.summers at intel.com>; Harrison, John C <john.c.harrison at intel.com>; Teres Alexis, Alan Previn <alan.previn.teres.alexis at intel.com>
Subject: [PATCH] drm/i915/wopcm: Handle pre-programmed WOPCM registers
Starting from DG2, some of the programming previously done by i915 and the GuC has been moved to the GSC and the relevant registers are no longer writable by either CPU or GuC. This is also referred to as GuC deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer programmed by the driver and we do instead expect to find them already set. This can lead to verification failures because in i915 we cheat a bit with the WOPCM size defines, to keep the code common across platforms, by sometimes using a smaller WOPCM size that the actual HW support (which isn't a problem because the extra size is not needed if the FW fits in the smaller chunk), while the pre-programmed values can use the actual size.
Given tha the new programming entity is trusted, relax the amount of the checks done on the pre-programmed values by not limiting the max programmed size. In the extremely unlikely scenario that the registers have been misprogrammed, we will still fail later at DMA time.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
Cc: Stuart Summers <stuart.summers at intel.com>
Cc: John Harrison <john.c.harrison at intel.com>
Cc: Alan Previn <alan.previn.teres.alexis at intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 3 ++
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/intel_device_info.c | 8 +++++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_wopcm.c | 42 ++++++++++++++++++----
6 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
index 93b251b25aba..88aad892a0fc 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -394,6 +394,14 @@ void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
}
+
+ /*
+ * Early DG2 steppings don't have the GuC depriv feature. We can't
+ * rely on the fuse on those platforms because the meaning of the fuse
+ * bit is inverted on platforms that do have the feature.
+ */
+ if (IS_DG2_GRAPHICS_STEP(dev_priv, G10, STEP_A0, STEP_A1))
+ info->has_guc_deprivilege = 0;
Nit: not sure if it matters if this stepping is not-public (although I am not 100% sure I am correct in my assumption this is not-public).
}
More information about the Intel-gfx
mailing list