drm/i915/gsc: implement wa 14015076503
authorDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Thu, 23 Mar 2023 23:18:57 +0000 (16:18 -0700)
committerDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Tue, 28 Mar 2023 19:15:10 +0000 (12:15 -0700)
commitb7d70b8b06edf25c4b7526e20f5b3d11175cab81
tree89e67dd76d39c135b0c683225b7f5fe51d4e3096
parent625af47255d9b30e22d6c98b7f5e97adc903b98e
drm/i915/gsc: implement wa 14015076503

The WA states that we need to alert the GSC FW before doing a GSC engine
reset and then wait for 200ms. The GuC owns engine reset, so on the i915
side we only need to apply this for full GT reset.

Given that we do full GT resets in the resume paths to cleanup the HW
state and that a long wait in those scenarios would not be acceptable,
a faster path has been introduced where, if the GSC is idle, we try first
to individually reset the GuC and all engines except the GSC and only fall
back to full reset if that fails.

Note: according to the WA specs, if the GSC is idle it should be possible
to only wait for the uC wakeup time (~15ms) instead of the whole 200ms.
However, the GSC FW team have mentioned that the wakeup time can change
based on other things going on in the HW and pcode, so a good security
margin would be required. Given that when the GSC is idle we already
skip the wait & reset entirely and that this reduced wait would still
likely be too long to use in resume paths, it's not worth adding support
for this reduced wait.

v2: add comment to explain why it is safe to skip the GSC reset (John)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323231857.2194435-2-daniele.ceraolospurio@intel.com
drivers/gpu/drm/i915/gt/intel_reset.c
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
drivers/gpu/drm/i915/i915_reg.h