[alsa-devel] [RFC 00/15] Add Samus Hotwording for RT5677

[Curtis Malainey]

Curtis Malainey | Software Engineer | cujomalainey at google.com | 650-898-3849


On Fri, Sep 6, 2019 at 1:41 PM Pierre-Louis Bossart <
pierre-louis.bossart at 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.