[PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace
Kai Vehmanen
kai.vehmanen at linux.intel.com
Tue Nov 29 13:11:34 CET 2022
Hi
On Tue, 29 Nov 2022, Takashi Iwai wrote:
> On Mon, 28 Nov 2022 18:26:03 +0100, Pierre-Louis Bossart wrote:
> > As Kai mentioned it, this step helped with a S5 issue earlier in 2022.
> > Removing this will mechanically bring the issue back and break other
> > Chromebooks.
>
> Yeah I don't mean that this fix is right, either. But the earlier fix
> has apparently a problem and needs another fix.
>
> Though, it's not clear why the full unregister of clients is needed at
> the first place; judging only from the patch description of commit
> 83bfc7e793b5, what we want is only to shut up the further user space
> action? If so, just call snd_card_disconnect() would suffice?
I think the snd_card_disconnect() is what we are looking after here, but
it's just easiest to do via unregister in SOF as that will trigger will
look up the platform device, unregister it, and it eventually the driver
owning the card will do the disconnect. Possibility for sure to do a more
direct implementation and not run the full unregister.
On the other end of the solution spectrum, we had this alternative to let
user-space stay connected and just have the DSP implementations handle
any pending work in their respective shutdown handlers. I.e. we had
"ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed"
https://github.com/thesofproject/linux/pull/3388
This was eventually dropped (and never sent upstream) as 83bfc7e793b5 got
the same result, and covered all SOF platforms with a single code path.
Bringing this back is of course one option, but then this might suprise
other platforms (which might have got used to user-space getting
disconnected at shutdown via 83bfc7e793b5).
Br, Kai
More information about the Alsa-devel
mailing list