drm/msm: split DPU core IRQ handler under CONFIG_PREEMPT_RT - #1738
drm/msm: split DPU core IRQ handler under CONFIG_PREEMPT_RT#1738namathak wants to merge 1 commit into
Conversation
On a PREEMPT_RT kernel, dpu_core_irq() runs as a true hardirq handler, but it dispatches per-encoder callbacks that take sleepable locks (spinlock_t becomes an rt_mutex on RT, and some DRM-core locks reached through vblank/CRC/writeback handling are sleepable as well). Sleeping inside a hardirq handler is not allowed and eventually crashes the display, which is what happens after running GLMark2 for a while. Split dpu_core_irq() into a minimal hardirq handler that only acknowledges the hardware and records which interrupts fired, plus a new dpu_core_irq_thread() that performs the actual callback dispatch from a real, preemptible IRQ thread. This split only takes effect under CONFIG_PREEMPT_RT; non-RT kernels keep dispatching callbacks directly from dpu_core_irq() as before. irq_lock is changed from spinlock_t to raw_spinlock_t unconditionally, since the hardirq handler needs a lock that never sleeps under RT, and raw_spinlock_t behaves the same as spinlock_t on non-RT kernels. dpu_core_irq() itself now takes irq_lock with plain raw_spin_lock() instead of raw_spin_lock_irqsave(), dropping the irqsave/irqrestore pair it previously needed as a bottom-half-safe spinlock user. This is safe because dpu_core_irq() only ever runs as a primary IRQ handler (hardirq context on non-RT, forced-thread primary handler on RT), both of which are always entered with local IRQs already disabled by genirq before the handler is called, so there is nothing left for irqsave to save here. dpu_core_irq_read(), by contrast, is called from process context and still needs raw_spin_lock_irqsave(). Fixes: 25fdd59 ("drm/msm: Add SDM845 DPU support") Cc: [email protected] Signed-off-by: Naman S Thaker <[email protected]>
🔨 Build Failure Analysis — PR #1738PR: #1738
VerdictAll 3 failures are pre-existing merge conflicts unrelated to this PR. The PR modifies only DPU IRQ handling code ( 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1738PR: #1738
VerdictAll 3 merge conflicts are pre-existing issues in the integration branch; none are introduced by this PR. 📎 Detailed analysis: Full report |
PR #1738 — validate-patchPR: #1738
Final Summary
|
PR #1738 — checker-log-analyzerPR: #1738
Detailed report: Full report
|
2 participants
On a PREEMPT_RT kernel, dpu_core_irq() runs as a true hardirq handler, but it dispatches per-encoder callbacks that take sleepable locks (spinlock_t becomes an rt_mutex on RT, and some DRM-core locks reached through vblank/CRC/writeback handling are sleepable as well). Sleeping inside a hardirq handler is not allowed and eventually crashes the display, which is what happens after running GLMark2 for a while.
Split dpu_core_irq() into a minimal hardirq handler that only acknowledges the hardware and records which interrupts fired, plus a new dpu_core_irq_thread() that performs the actual callback dispatch from a real, preemptible IRQ thread. This split only takes effect under CONFIG_PREEMPT_RT; non-RT kernels keep dispatching callbacks directly from dpu_core_irq() as before.
irq_lock is changed from spinlock_t to raw_spinlock_t unconditionally, since the hardirq handler needs a lock that never sleeps under RT, and raw_spinlock_t behaves the same as spinlock_t on non-RT kernels.
dpu_core_irq() itself now takes irq_lock with plain raw_spin_lock() instead of raw_spin_lock_irqsave(), dropping the irqsave/irqrestore pair it previously needed as a bottom-half-safe spinlock user. This is safe because dpu_core_irq() only ever runs as a primary IRQ handler (hardirq context on non-RT, forced-thread primary handler on RT), both of which are always entered with local IRQs already disabled by genirq before the handler is called, so there is nothing left for irqsave to save here. dpu_core_irq_read(), by contrast, is called from process context and still needs raw_spin_lock_irqsave().
Fixes: 25fdd59 ("drm/msm: Add SDM845 DPU support")
Cc: [email protected]
CRs-Fixed: 4642652