Re: [alsa-devel] [RFC 00/15] Add Samus Hotwording for RT5677 - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Curtis Malainey <cujomalainey@google.com>
Cc: Curtis Malainey <cujomalainey@chromium.org>,
	ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [alsa-devel] [RFC 00/15] Add Samus Hotwording for RT5677
Date: Fri, 6 Sep 2019 17:13:00 -0500	[thread overview]
Message-ID: <b1de1190-d809-9cb3-3560-97595df895d3@linux.intel.com> (raw)
In-Reply-To: <CAOReqxgJQaW=XAsD4o9hq_iU1faJBK3d9Rg8FCp_4Mrx3UX-oQ@mail.gmail.com>

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,
> 
>  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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel