Re: [PATCH V2] ASoC: soc-pcm: BE dai needs prepare when pause release after resume

[Ranjani Sridharan <ranjani.sridharan@linux.intel.com>]

> Hm, it's a good question.  Currently the PCM core doesn't care about
> the paused stream wrt PM by the assumption that the paused / stopped
> stream doesn't need a special resume treatment.  But, generally
> speaking, the pause-release won't work for a hardware that doesn't
> support the full resume, either.  For example, the legacy HD-audio
> may
> restart from some wrong position if resumed from the pause.
> 
> Maybe this problem hasn't been seen just because the pause function
> is
> rarely used.
> 
> So, the safe behavior would be to let the stream being SUSPENDED
> state
> at snd_pcm_stream_suspend() when it's in the PAUSED and has no
> INFO_RESUME capability.  Then the application does re-prepare the
> stream like the running one.
> 
> But the question is what's expected at next.  Should the application
> re-start?  But it was paused.  Should PCM core automatically move to
> pause?  But most hardware can't move the pointer to any random
> position.
> 
> My gut feeling is just to treat like a normal error-restart,
> i.e. re-prepare / re-start.  But I'm open and would like to hear more
> opinions.

Hi Takashi,

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. 

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?

Thanks,
Ranjani