On Mon, 30 May 2022 12:34:15 +0200,
Charles Keepax wrote:
On Mon, May 30, 2022 at 12:14:26PM +0200, Takashi Iwai wrote:
On Mon, 30 May 2022 11:36:39 +0200,
Charles Keepax wrote:
On Mon, May 30, 2022 at 11:18:43AM +0200, Takashi Iwai wrote:
On Mon, 30 May 2022 11:08:46 +0200,Yeah that should be what is happening here. Although it looks
Charles Keepax wrote:
On Fri, May 27, 2022 at 06:13:38PM +0200, Takashi Iwai wrote:
On Wed, 25 May 2022 15:16:21 +0200,
Vitaly Rodionov wrote:
like this code might be removing all the controls if the firmware
is unloaded. I will discuss that with the guys, we normal just
disable the controls on the wm_adsp stuff.
OK, that sounds good. Basically my concern came up from the code
snippet doing asynchronous addition/removal via work. This showed
some yellow signal, as such a pattern doesn't appear in the normal
implementation. If this is (still) really necessary, it has to be
clarified as an exception.
Hm... ok we will think about that. I think that part will
probably still be necessary. Because there is an ALSA control
that selects the firmware, then it is necesarry to defer creating
the controls to some work, since you are already holding the
lock.
Well, if an ALSA control can trigger the firmware loading, that's
already fragile. A firmware loading is a heavy task, which should
happen only at probing and/or resuming in general. Do we have other
drivers doing the f/w loading triggered by a kctl...?