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@xxxxxxxxxxxxxxx> 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 -- Ricardo Ribalda
