On Fri, Nov 14, 2025 at 05:01:45PM -0800, Niranjana Vishwanathapura wrote: > On Thu, Oct 16, 2025 at 01:48:26PM -0700, Matthew Brost wrote: > > If the firmware is not running during TDR (e.g., when the driver is > > unloading), there's no need to toggle scheduling in the GuC. In such > > cases, skip this step. > > > > Signed-off-by: Matthew Brost <[email protected]> > > --- > > drivers/gpu/drm/xe/xe_guc_submit.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c > > b/drivers/gpu/drm/xe/xe_guc_submit.c > > index bb1f2929441c..ea0cfd866981 100644 > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c > > @@ -1146,7 +1146,7 @@ guc_exec_queue_timedout_job(struct drm_sched_job > > *drm_job) > > if (exec_queue_reset(q)) > > err = -EIO; > > > > - if (!exec_queue_destroyed(q)) { > > + if (!exec_queue_destroyed(q) && xe_uc_fw_is_running(&guc->fw)) { > > /* > > * Wait for any pending G2H to flush out before > > * modifying state > > Looking at the code, it seems like if we skip this 'if' statement (when fw is > not running), then it will go wait for ct->wq. Not sure how that gets woken up > and logic might try to reset gt after that? Not sure if we should check > xe_uc_fw_is_running() here will one of the conditions to wait_event_timeout() > call cover this case and we can handle it appropriately after > wait_event_timeout() > returns?
I believe exec_queue_pending_disable will never be true, but maybe there is race there. Let me and this condition for safety. Matt > > Niranjana > > > -- > > 2.34.1 > >
