Hi
I just sent a v6 that only avoids unregistering the clients during kexec... let me know if that works for you
Thanks!
On Tue, 29 Nov 2022 at 13:12, Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
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