| Message ID | 20230607124941.19016-1-stanislav.lisovskiy@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/mst: Make sure all resources are freed for MST topology manager before destroy | expand |
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index 3ba4a2fef98a..9c587b40cf42 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -1298,6 +1298,7 @@ intel_dp_mst_encoder_cleanup(struct intel_digital_port *dig_port) if (!intel_dp_mst_source_support(intel_dp)) return; + drm_dp_mst_topology_mgr_suspend(&intel_dp->mst_mgr); drm_dp_mst_topology_mgr_destroy(&intel_dp->mst_mgr); /* encoders will get killed by normal cleanup */
In some of the CI failures we have see a race condition, when we were getting continuous hpd pulses, forcing DP MST topology manager to try handling them, however if this is combined with module reload that might cause it to try destroying the already locked mutex, also some workqueue might attempt to use already freed encoder resources, because drm_dp_mst_topology_mgr_destroy doesn't check if mutex is still locked(triggers WARN) and flushes only one drm_dp_mst_link_probe_work queue, while others, like drm_dp_mst_up_req_work might be running at the moment, especially in case if due to some other sw/hw bug, we are constantly getting hpd pulses from MST device. Best way would be to modify drm_dp_mst_topology_mgr_destroy function itself, however as it might take way more time, for now lets try to call drm_dp_mst_topology_mgr_suspend first, which seems to do all the required actions. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 + 1 file changed, 1 insertion(+)