ASoC: SOF: sof-pcm/pm: On system suspend, move the paused streams to … #5040
Conversation
…suspended state Paused streams will not receive a suspend trigger, they will be marked by ALSA core as suspended and it's state is saved. Since the pause stream is not in a fully stopped state, for example DMA might be still enabled (just the trigger source is removed/disabled) we need to make sure that the hardware is ready to handle the suspend. This involves a bit more than just stopping a DMA since we also need to communicate with the firmware in a delicate sequence to follow IP programming flows. To make things a bit more challenging, these flows are different between IPC versions due to the fact that they use different messages to implement the same functionality. To avoid adding yet another path, callbacks and sequencing for handling the corner case of suspending while a stream is paused, and do this for each IPC versions and platforms, we can move the stream back to running just to put it to suspended state. In this way we will essentially reduce the suspend cases to two: no audio and running audio (the paused audio becomes a running audio case), cutting down on the probability of misaligned handling of cases. Link: thesofproject#5035 Signed-off-by: Peter Ujfalusi <[email protected]>
ujfalusi
requested review from
dbaluta,
plbossart,
lyakh,
bardliao,
lgirdwood,
ssavati,
kv2019i,
bhiregoudar and
yaochunhung
|
|
||
| /* | ||
| * Paused streams will not receive a suspend trigger | ||
| * but moved to suspended state. |
It will fail to reset all pipelines as the pause_count (or the started_count) is no zero (lost the old logs), but anyways, currently you will not see that as the device locks up on suspend. ret = hda_dai_trigger(hext_stream->link_substream,
SNDRV_PCM_TRIGGER_SUSPEND,
cpu_dai);can fix the system freeze, but then the IPC messages are failing as we have the imbalance and the pipelines are in wrong state. |
|
I am starting to wonder if this shouldn't be a supported functionality in ALSA/ASoC frameworks, rather than requiring work-around in SoundWire and now PCM/HDaudio? The missing trigger seems like a true design miss. |
The transition from PAUSED to SUSPENDED needs the stream to be taken to RUNNING for some reason for things to actually work, if you look at I'm sure if we change the core to send a SUSPEND trigger to a PAUSED stream we will see all sorts of issues with other drivers, so that would need some alignment and care. There must be a reason why it is like this... |
|
Looks like I have found several bugs and likely the issue can be fixed in a more complicated way... |
| "%s: SUSPEND failed for %s (id: %d): %d\n", | ||
| __func__, substream->name, | ||
| spcm->pcm.pcm_id, ret); | ||
| return ret; |
There was a problem hiding this comment.
We need to have separate runs to first send the PAUSE_RELEASE then in next scan, the SUSPEND to handle the case with multiple paused streams with shared pipeline section.
…suspended state
Paused streams will not receive a suspend trigger, they will be marked by ALSA core as suspended and it's state is saved.
Since the pause stream is not in a fully stopped state, for example DMA might be still enabled (just the trigger source is removed/disabled) we need to make sure that the hardware is ready to handle the suspend.
This involves a bit more than just stopping a DMA since we also need to communicate with the firmware in a delicate sequence to follow IP programming flows.
To make things a bit more challenging, these flows are different between IPC versions due to the fact that they use different messages to implement the same functionality.
To avoid adding yet another path, callbacks and sequencing for handling the corner case of suspending while a stream is paused, and do this for each IPC versions and platforms, we can move the stream back to running just to put it to suspended state.
In this way we will essentially reduce the suspend cases to two: no audio and running audio (the paused audio becomes a running audio case), cutting down on the probability of misaligned handling of cases.
Link: #5035