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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CF33C36214C39B4496568E5578BE70C740320822@PGSMSX108.gar.corp.intel.com>
Date:   Fri, 25 Oct 2019 14:43:12 +0000
From:   "Lu, Brent" <brent.lu@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
CC:     "Rojewski, Cezary" <cezary.rojewski@...el.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Jie Yang <yang.jie@...ux.intel.com>,
        "Mark Brown" <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        "Subhransu S . Prusty" <subhransu.s.prusty@...el.com>,
        Richard Fontana <rfontana@...hat.com>,
        Tzung-Bi Shih <tzungbi@...gle.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "M, Naveen" <naveen.m@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [alsa-devel] [PATCH] ASoC: eve: implement set_bias_level
 function for rt5514

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

Regards,
Brent
> > This rt5514 codec requires to control mclk directly in the
> > set_bias_level function. Implement this function in machine driver to
> > control the ssp1_mclk clock explicitly could fix this issue.
> >
> > Signed-off-by: Brent Lu <brent.lu@...el.com>