diff options
| author | Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> | 2026-07-13 13:23:16 -0700 |
|---|---|---|
| committer | Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> | 2026-07-13 13:29:20 -0700 |
| commit | 65f40fa5022bcdb90d3a39e4948adf2aa16732a3 (patch) | |
| tree | 57c570af02761198e138a426c8883c49dab45c80 /tools/perf/scripts/python/bin | |
| parent | 068388c0cd225654e7369907670d4e77b8dd3744 (diff) | |
drm/xe: only resume exec queues that were actually suspended
A consumer-issued suspend() can fail (e.g. the queue is killed, banned
or wedged), leaving the queue un-suspended. The consumer must then not
issue the matching resume(): resuming a queue that was never suspended
is incorrect.
Add an lr.suspended flag to struct xe_exec_queue that records whether a
consumer suspend() succeeded and a matching resume() is still owed. Set
it on a successful suspend() in the preempt-fence path, clear it on
resume(), and only resume queues that have it set.
In resume_and_reinstall_preempt_fences() also skip queues that have
since been reset/killed/banned/wedged: such a queue's suspend may not
have completed (suspend_pending can still be set, e.g. a preempt fence
signalled with -ENOENT without waiting), so resuming it would trip the
!suspend_pending assert in the backend. Leave it marked suspended and
let teardown resolve its state.
A queue is only ever suspended by a single consumer at a time
(preempt-fence mode and hw engine group fault mode are mutually
exclusive), so a single flag is sufficient.
Assisted-by: Github-Copilot:Claude-opus-4.8
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260713202317.2187787-9-niranjana.vishwanathapura@intel.com
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
