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

[Joonhoe Kim <26rote@gmail.com>]

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?

Thanks,
Joonhoe Kim