On 2022-11-07 3:28 PM, Mark Brown wrote:
It'd be good to at least have some idea of practical usage as well, the functions return void because nothing was making any use of the return values.
The problem is mainly connected to a resume operation as even if something fails at suspend, there is a chance for the driver to recover things up during resume.
Now, if something fails during the resume operation, blindly returning 0 makes userspace think everything is fine and we can keep going, whereas the stream may no longer be operational and requires complete recovery (close, reopen).
alsa-utils/aplay/aplay.c does snd_pcm_resume() as long as -EAGAIN is returned, then falls back to snd_pcm_prepare() before finally giving up. As snd_pcm_prepare() checks pcm's state before invoking ->prepare(), one option is to set substream->runtime->status->state to SNDRV_PCM_STATE_DISCONNECTED to ensure dai->hw_free() gets called right after.
TLDR: it all comes down to some granularity missing. Suspend/resume for the AudioDSP drivers do basically entire pcm-lifecycle within what is supposed to be a simple TRIGGER_SUSPEND/RESUME operation.
There's also an expectation that suspend and resume be fast...
You're right. Sound devices should not disturb the PM for the entire system.
Looking at this after thinking the performance/stability argument through, indeed deferring work is a good way of dealing with the situation.
Regards, Czarek