On Fri, Sep 6, 2019 at 3:13 PM Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > > 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. > 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 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? 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. > > > 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
