Conversation
When a capture stream for WoV is active during suspend, we must not tear down the pipelines as they must remain active while the system is suspended. In order to the WoV to work with system suspend, the PCM must have SNDRV_PCM_INFO_RESUME set so applications will not try to re-start the stream due to not supported resume trigger. However on RESUME trigger there is nothing to do for the VoW PCM as it was left running, but since system RESUME is not supported by default, for other streams which have suspend_ignored=false we need to return error for userspace to restart the stream. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
…treams VoW streams can be identified with the d0i3_compatible flag and for the Wake on Voice to work the SNDRV_PCM_INFO_RESUME flag must be set for the PCM. On system suspend the DSP will be left enabled, pipelines running and on resume there will be no action needed to be done. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Resolve the HDA RESUME handling and restrict or implement resume support for non-retained suspend paths.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Fixes SOF Wake on Voice suspend/resume by retaining pipelines during D0 suspend and enabling ALSA resume support.
Changes:
- Avoids pipeline teardown when suspending to D0.
- Handles RESUME for retained streams.
- Advertises RESUME for compatible HDA capture streams.
| File | Summary | Review status |
|---|---|---|
sound/soc/sof/pm.c |
Preserves pipelines during D0 suspend. | No issue noted. |
sound/soc/sof/pcm.c |
Handles RESUME for suspend-ignored streams. | Moderate issue: the HDA DAI path can still return -EINVAL for RESUME. |
sound/soc/sof/intel/hda-pcm.c |
Advertises resume capability for VoW capture streams. | Moderate issue: capability is advertised for paths that do not reliably support RESUME. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+360
to
+362
| if (direction == SNDRV_PCM_STREAM_CAPTURE && | ||
| spcm->stream[substream->stream].d0i3_compatible) | ||
| runtime->hw.info |= SNDRV_PCM_INFO_RESUME; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Wake on Voice flow was broken (supported via IPC3 only atm) because on suspend we attempted to tear down the pipelines
and RESUME was not supported by the PCM:
We had errors on suspend due to failing to free widgets and the user space restarted to capture during resume.
To fix this:
If the target suspend level is SOF_DSP_PM_D0 then we must not tear down the pipelines
we need to set the SNDRV_PCM_INFO_RESUME for the VoW capture PCM, so applications can do the 'resume'
and on RESUME trigger we do nothing as the DSP was left on and everything has been left running as they were before.
Tested on sof-adl-max98357a-rt5682.tplg with:
and
then clapping to wake the device up: no errors observed anymore.