[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiDSCsGZBo=C+Bep8TQp15mA+-4ZRCPwSJzyndFuwokt7Byyw@mail.gmail.com>
Date: Wed, 30 Nov 2022 16:49:26 +0100
From: Ricardo Ribalda <ribalda@...omium.org>
To: Kai Vehmanen <kai.vehmanen@...ux.intel.com>
Cc: Takashi Iwai <tiwai@...e.de>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
Takashi Iwai <tiwai@...e.com>, stable@...r.kernel.org,
Mark Brown <broonie@...nel.org>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Daniel Baluta <daniel.baluta@....com>,
linux-kernel@...r.kernel.org, sound-open-firmware@...a-project.org
Subject: Re: [PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace
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@...ux.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
--
Ricardo Ribalda
Powered by blists - more mailing lists