Re: [PATCH 2/2] media: qcom: iris: Wait for threaded IRQ completion during power-off

[Vishnu Reddy <busanna.reddy@oss.qualcomm.com>]

On 11/3/2026 3:35 AM, Joonhoe Kim wrote:
> Hi Vishnu,
>
> Without the series, I hit the same deadlock on a Lenovo Y700 Gen 5
> (TB323FU, Kaanapali, v7.3-rc). It happened when removing the module
> right after a decode session. rmmod waited in __synchronize_irq(),
> and the iris IRQ thread in iris_hfi_isr_handler() waited for
> core->lock. A loop of decode, rmmod and modprobe reproduced it in
> round 4 of 20.
>
> With both patches on v7.3 and out-of-tree Kaanapali support, the same
> loop passed 60 of 60 rounds. 2/2 needed context changes only. H.264,
> HEVC and VP9 decodes still matched software decoding.
>
> Tested-by: Joonhoe Kim <26rote@gmail.com> # Kaanapali
>
> One question. While core->lock is dropped around disable_irq(), some
> callers take core->lock directly rather than through
> iris_acquire_core_lock(): iris_hfi_queue_cmd_write(),
> iris_set_clocks() and iris_set_interconnects(). These are not held off
> by irq_disabling. Also, in iris_core_deinit() the firmware is already
> unloaded at that point, while core->state is still IRIS_CORE_INIT. Is
> that window meant to be safe?

Thank you for testing this on Kaanapali.

core->lock is dropped around disable_irq(), and all power-down steps run after
it is retaken, so the hardware is still powered on and queue memory stays valid
throughout. A command queued after the firmware unload in iris_core_deinit() is
dropped. I didn't see any problem there.

>
> Thanks,
> Joonhoe Kim