Re: [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering

[Bui Duc Phuc]

Hi Morimoto-san,

I’ve looked into this further and would like to share my findings and
get your feedback on the next direction for addressing the issue.

The sequence is as follows:

(1) IRQ fires → handler starts
(2) handler is running

(3) playback ends → ALSA issues STOP
(4) fsi_dai_trigger(STOP)
    → active_streams = 0
    → fsi_hw_shutdown()
    → clock OFF

(5) IRQ handler continues
    → fsi_count_fifo_err()
    → register access → system hang

Since the trigger() runs in atomic context, we cannot use APIs like
disable_irq() / disable_irq_sync()
to synchronize with the IRQ handler.
As a possible approach, I’m considering guarding against register
access in the IRQ path when no streams are active,
for example by adding:

if (master->active_streams == 0)
    return;

at the beginning of:
+ fsi_count_fifo_err()
+ fsi_irq_clear_status()

To support this, we would need to track the active streams by:
+ adding a running flag per stream
+ adding an active_streams counter in struct fsi_master

and update them in trigger():

if (!io->running) {
    io->running = true;
    master->active_streams++;
}

if (io->running) {
    io->running = false;
    master->active_streams--;
}

With this approach, even if a pending IRQ is handled after shutdown,
the handler would avoid accessing registers, preventing the system
hang.
I’d appreciate your feedback on whether this approach looks reasonable
or if there is a better way to handle this.

The issue is reproducible when playback reaches EOF, while not
observed in some other stop scenarios such as manual interruption.

Best regards,
Phuc