linux-kernel - Re: [alsa-devel] [PATCH] ASoC: eve: implement set_bias

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <618b3202-6418-a7e2-9b8e-bc32c01d46ed@linux.intel.com>
Date:   Fri, 25 Oct 2019 11:57:26 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     "Lu, Brent" <brent.lu@...el.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Cc:     "Rojewski, Cezary" <cezary.rojewski@...el.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Tzung-Bi Shih <tzungbi@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jie Yang <yang.jie@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Richard Fontana <rfontana@...hat.com>,
        Mark Brown <broonie@...nel.org>,
        "M, Naveen" <naveen.m@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Subhransu S . Prusty" <subhransu.s.prusty@...el.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: eve: implement set_bias_level function
 for rt5514



On 10/25/19 11:14 AM, Lu, Brent wrote:
>>
>> Can you clarify if the rt5514 needs the MCLK while it's doing the hotword
>> detection?
> 
> No, running the detection does not raise the bias level so the set_bias_level
> will not be called. The mclk is only turned on then off in mixer control's handler
> (rt5514_dsp_voice_wake_up_put) when enabling the hotword detection.
> 
>>
>> My point is really that this patch uses a card-level BIAS indication, and I'd like
>> to make sure this does not interfere with the audio DSP being in D3 state.
> 
> The function checks the name of dapm so it would only react when rt5514's
> bias level is changing. And also the idle_bias_off of the codec driver is true so
> it's target_bias_level should not be overwritten in the dapm_power_widgets()
> function. The behavior should be similar to the previous patch which is using
> supply widget.

Ah yes, I did miss this test:

+	if (!component || strcmp(component->name, RT5514_DEV_NAME))
+		return 0;

Looks good then, thanks for the explanations.

Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>