Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <008e3188-f35d-4323-08ea-de5f3a88333a@opensource.cirrus.com>
Date:   Wed, 1 Jun 2022 17:43:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [PATCH v4 00/17] ALSA: hda: cirrus: Add initial DSP support and
 firmware loading
Content-Language: en-US
To:     Takashi Iwai <tiwai@suse.de>,
        Charles Keepax <ckeepax@opensource.cirrus.com>
CC:     Vitaly Rodionov <vitalyr@opensource.cirrus.com>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, Mark Brown <broonie@kernel.org>,
        <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
        <linux-kernel@vger.kernel.org>
References: <20220525131638.5512-1-vitalyr@opensource.cirrus.com>
 <871qwf0x8t.wl-tiwai@suse.de>
 <20220530090846.GS38351@ediswmail.ad.cirrus.com>
 <87czfvxtsc.wl-tiwai@suse.de>
 <20220530093639.GT38351@ediswmail.ad.cirrus.com>
 <87a6azxr7h.wl-tiwai@suse.de>
 <20220530103415.GU38351@ediswmail.ad.cirrus.com>
 <871qwbxpsb.wl-tiwai@suse.de>
From:   Richard Fitzgerald <rf@opensource.cirrus.com>
In-Reply-To: <871qwbxpsb.wl-tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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().