drm/i915/gsc: flush the GSC worker before wedging on unload

If we unload the driver and wedge before the GSC worker is complete,
the worker will hit an error on its submission to the GSC engine and
then exit. This is hard to hit for a user, but it is reproducible
with skipping selftests. The error is handled gracefully by the
worker, so there are no functional issues, but we still end up with
an error message in dmesg, which is something we want to avoid as
this is a supported scenario. We could modify the worker to better
handle a wedging occurring during its execution, but that gets
complicated for a couple of reasons:
- We do want the error on runtime wedging, because there are
  implications for subsystems outside of GT (i.e., PXP, HDCP), it's
  only the error on driver unload that we want to silence.
- The worker is responsible for multiple submissions (GSC FW load,
  HuC auth, SW proxy), so all of those will have to be adapted to
  handle the wedged_on_fini scenario.
Therefore, it's much simpler to just wait for the worker to be done
before wedging on driver removal, also considering that the worker
will likely already be idle in the great majority of non-selftest
scenarios.
Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: default avatarAlan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223172120.3304293-2-daniele.ceraolospurio@intel.com
parent e67db9d2
......@@ -784,6 +784,29 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
intel_rps_driver_unregister(&gt->rps);
intel_gsc_fini(&gt->gsc);
/*
* If we unload the driver and wedge before the GSC worker is complete,
* the worker will hit an error on its submission to the GSC engine and
* then exit. This is hard to hit for a user, but it is reproducible
* with skipping selftests. The error is handled gracefully by the
* worker, so there are no functional issues, but we still end up with
* an error message in dmesg, which is something we want to avoid as
* this is a supported scenario. We could modify the worker to better
* handle a wedging occurring during its execution, but that gets
* complicated for a couple of reasons:
* - We do want the error on runtime wedging, because there are
* implications for subsystems outside of GT (i.e., PXP, HDCP), it's
* only the error on driver unload that we want to silence.
* - The worker is responsible for multiple submissions (GSC FW load,
* HuC auth, SW proxy), so all of those will have to be adapted to
* handle the wedged_on_fini scenario.
* Therefore, it's much simpler to just wait for the worker to be done
* before wedging on driver removal, also considering that the worker
* will likely already be idle in the great majority of non-selftest
* scenarios.
*/
intel_gsc_uc_flush_work(&gt->uc.gsc);
/*
* Upon unregistering the device to prevent any new users, cancel
* all in-flight requests so that we can quickly unbind the active
......
......@@ -116,7 +116,7 @@ void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
intel_uc_fw_fini(&gsc->fw);
}
void intel_gsc_uc_suspend(struct intel_gsc_uc *gsc)
void intel_gsc_uc_flush_work(struct intel_gsc_uc *gsc)
{
if (!intel_uc_fw_is_loadable(&gsc->fw))
return;
......
......@@ -26,6 +26,7 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc);
int intel_gsc_uc_init(struct intel_gsc_uc *gsc);
void intel_gsc_uc_fini(struct intel_gsc_uc *gsc);
void intel_gsc_uc_suspend(struct intel_gsc_uc *gsc);
void intel_gsc_uc_flush_work(struct intel_gsc_uc *gsc);
void intel_gsc_uc_load_start(struct intel_gsc_uc *gsc);
static inline bool intel_gsc_uc_is_supported(struct intel_gsc_uc *gsc)
......
......@@ -672,7 +672,7 @@ void intel_uc_suspend(struct intel_uc *uc)
int err;
/* flush the GSC worker */
intel_gsc_uc_suspend(&uc->gsc);
intel_gsc_uc_flush_work(&uc->gsc);
if (!intel_guc_is_ready(guc)) {
guc->interrupts.enabled = false;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment