diff options
| author | Rodrigo Vivi <rodrigo.vivi@intel.com> | 2023-07-27 00:30:42 +0300 |
|---|---|---|
| committer | Rodrigo Vivi <rodrigo.vivi@intel.com> | 2023-12-21 19:39:15 +0300 |
| commit | f83a30f466ebbd56355b1f65ec9bcd5087840ffc (patch) | |
| tree | 0fa07ba0ceeec0fdd6b2b27ae06023d20a578787 /include | |
| parent | fda48d15a4eade29a41d46d5a6f0bfa7556ccb72 (diff) | |
| download | linux-f83a30f466ebbd56355b1f65ec9bcd5087840ffc.tar.xz | |
drm/xe: Fix an invalid locking wait context bug
We cannot have spin locks around xe_irq_reset, since it will
call the intel_display_power_is_enabled() function, and
that needs a mutex lock. Hence causing the undesired
"[ BUG: Invalid wait context ]"
We cannot convert i915's power domain lock to spin lock
due to the nested dependency of non-atomic context waits.
So, let's move the xe_irq_reset functions from the
critical area, while still ensuring that we are protecting
the irq.enabled and ensuring the right serialization
in the irq handlers.
v2: On the first version, I had missed the fact that
irq.enabled is checked on the xe/display glue layer,
and that i915 display code is actually using the irq
spin lock properly. So, this got changed to a version
suggested by Matthew Auld.
v3: do not use lockdep_assert for display glue.
do not save restore irq from inside IRQ or we can
get bogus irq restore warnings
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/463
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
