Curtis Malainey | Software Engineer | cujomalainey@google.com | 650-898-3849
On Fri, Sep 6, 2019 at 1:41 PM Pierre-Louis Bossart < pierre-louis.bossart@linux.intel.com> wrote:
On 9/6/19 2:46 PM, Curtis Malainey wrote:
This patch series adds the hotwording implementation used in the Pixelbook on the RT5677 driver.
Known Issues: There is a known issue where the system will fail to detect a hotword if suspended while the stream is open. This is due to the fact that the haswell-dsp suspends its I2S MCLK before the RT5677 suspends which causes the writes and reads to become corrupted as a result. Any recommendations to correct this behaviour would be appreciated.
I don't get what 'suspend' and 'stream' refer to. is this pm_runtime, s2idle, system capture, SPI capture?
Can you elaborate on the sequence?
Definitely can,
1. open hotwording pcm with arecord in non-blocking mode - Codec won't send any data over SPI until the hotword is detected 2. put system into S3 (see order of callbacks as follows) 1. HSW DSP suspended which suspends stops I2S MCLK 2. RT5677 suspended, all pm writes are lost due to the fact that the codec is still in DSP mode but has no clock 3. System resumes and fails to restore the RT5677 due to the fact that the regmap is now out of sync
The rt5677 needs to suspend before the haswell dsp but I am not sure how to schedule that appropriately. The reason this worked in Samus is because it launched with a 3.14 kernel which did not have 0d2135ecadb0b2eec5338a7587ba29724ddf612b ("ASoC: Intel: Work around to fix HW D3 potential crash issue") which powers down the MCLK when the haswell DSP is not in use.
Hope that clears things up.