[alsa-devel] [PATCH] ASoC: eve: implement set_bias_level function for rt5514

[Pierre-Louis Bossart]

On 10/25/19 9:43 AM, Lu, Brent wrote:
>> On 10/25/19 4:11 AM, Brent Lu wrote:
>>> The first DMIC capture always fail (zero sequence data from PCM port)
>>> after using DSP hotwording function (i.e. Google assistant).
>>
>> Can you clarify where the DSP hotwording is done? Intel DSP or rt5514?
>>
>> Turning on the MCLK with the BIAS info might force the Intel DSP to remain
>> on, which would impact power consumption if it was supposed to remain off.
>>
> 
> Hi Pierre,
> 
> It's done in rt5514's DSP and the interface is SPI instead of I2S for the voice wake
> up function.
> 
> There is a driver rt5514-spi.c which provides platform driver and DAI. User space
> application first uses the mixer to turn on the voice wake up function:
> 
> amixer -c0 cset name='DSP Voice Wake Up' on
> 
> Then open and read data from the PCM port which goes to the SPI platform and
> dai code. Finally it uses same mixer to turn off the function and return to normal
> codec mode. The DMIC recording (from I2S) and the voice wake on function should
> be mutually exclusive according to the driver design.
> 
> In the codec driver rt5514.c there is a rt5514_set_bias_level function. It's expected to
> turn on/off mclk here according to Realtek people's say but our ssp clock requires set
> rate function to be called in advance so I implement the code in machine driver.

Can you clarify if the rt5514 needs the MCLK while it's doing 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.