On 9/6/19 4:09 PM, Curtis Malainey wrote:
Curtis Malainey | Software Engineer | cujomalainey@xxxxxxxxxx
<mailto:cujomalainey@xxxxxxxxxx> | 650-898-3849
On Fri, Sep 6, 2019 at 1:41 PM Pierre-Louis Bossart
<pierre-louis.bossart@xxxxxxxxxxxxxxx
<mailto:pierre-louis.bossart@xxxxxxxxxxxxxxx>> 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)
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.
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
there'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?
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
