So in the current scenario what we see is that after resuming from S3, a pause-release action from the user results in a FE prepare() followed by the START trigger (and not a PAUSE-RELEASE trigger).
Libin's patch proposes to do a prepare() for the BE even in the case of a regular pause-release. But this might not be ideal since other drivers might have logic in the prepare() ioctl that might end up with errors.
Right.
So I am thinking maybe we can have some internal logic in the SOF prepare() callback that will also call the BE prepare() when the be->dpcm[stream].state is SND_SOC_DPCM_STATE_PAUSED? Would that
make
sense?
Yes, that would work, I guess. Eventually this might be needed to be addressed in ALSA core side, too, but it's good to have some fix beforehand in DPCM.
Ranjani, with "regular pause-release", do you mean pause-release without S3? The prepare() is called from alsa core (pcm_native.c) in S3 case. Prepare() being called in pause-release after S3 is because of S3, not because of pause-release. Actually, if you pause-release without S3 (not sure in pm-runtime case), ASoC's prepare() will not be called. So dpcm_be_dai_prepare() will not be called. So you assumption of "regular pause-release" calling prepare() is wrong.
Oh yes. That's right. Thanks for pointing it out. In this case, the patch sounds like a good fix. Basically, you're saying that if the FE prepare() gets called (which happens in the case of pause-release without INFO_RESUME) it should also call the BE prepare(), right?
Takashi, what do you think?
Please let me describe the flow below:
- Pause-release after S3 without RESUME_INFO
Prepare() -> trigger start 2. pause-release without S3 without/with RESUME_INFO Trigger pause-release
- Pause-release after S3 with RESUME_INFO
Trigger resume
Are you sure about this? A paused stream will not be suspended. So it would still be trigger PAUSE-RELEASE in this case?
Thanks, Ranjani