On Fri, Sep 6, 2019 at 3:13 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
On 9/6/19 4:09 PM, Curtis Malainey wrote:
Curtis Malainey | Software Engineer | cujomalainey@google.com mailto:cujomalainey@google.com | 650-898-3849
On Fri, Sep 6, 2019 at 1:41 PM Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com mailto: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,
- open hotwording pcm with arecord in non-blocking mode
- Codec won't send any data over SPI until the hotword is detected
- put system into S3 (see order of callbacks as follows)
Before we start digging into dependencies below, is it really possible to enter S3 with the hotwording open? I vaguely remember being told that such cases would be trapped by the Chrome userspace and the PCM would be closed. I don't think anyone on the SOF team testing this case for newer platform, so that case on an old platform makes me nervous.
I vaguely recall that as well now that you mention it. I will follow up internally, if that is true then this will be a non-issue from our point of view.
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 clockthere's no real dependency or parent-child relationship between the two drivers, is there? so I am wondering if this order is intentional or just accidental. The only thing I can think of is that there are multiple steps during the system suspend and maybe we can play with .suspend_late instead of .suspend?
Not that I am aware of, when used as a standard codec there is no clock dependency. I will try and see if I can set the pm accordingly.
- 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.