On Wed, 01 Jun 2022 18:43:31 +0200, Richard Fitzgerald wrote: > > On 30/05/2022 11:45, Takashi Iwai wrote: > > 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, > >>>>> 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: > >>>> Yeah that should be what is happening here. Although it looks > >>>> 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...? > > > > On Wolfson/Cirrus codecs the firmware isn't to "make the chip work". > The DSP is programmable to allow for additional audio processing > algorithms. Which algorithm you need depends on the audio use case(s) > you are running, and can change as you change use-case. Many of the > codecs don't have enough DSP memory to hold all possible algorithms. > Which is why the firmware load has always been triggered from ALSA > controls in the ASoC code. It's not something that can be loaded > once in probe(). But it's still a question whether such an easily triggerable interface should be used for a heavy procedure like the DSP firmware load. e.g. calling the standard request_firmware() API directly from a control callback doesn't sound like a good idea at all. The similar argument is applied to the dynamic addition/removal of other controls followed by a kctl callback. thanks, Takashi
