>-----Original Message----- >From: Takashi Iwai [mailto:tiwai@xxxxxxx] >Sent: Thursday, May 9, 2019 5:21 AM >To: Ranjani Sridharan <ranjani.sridharan@xxxxxxxxxxxxxxx> >Cc: Yang, Libin <libin.yang@xxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx; >Sridharan, Ranjani <ranjani.sridharan@xxxxxxxxx>; pierre- >louis.bossart@xxxxxxxxxxxxxxx; Wang, Rander <rander.wang@xxxxxxxxx>; >broonie@xxxxxxxxxx >Subject: Re: [PATCH V2] ASoC: soc-pcm: BE dai needs prepare >when pause release after resume > >On Wed, 08 May 2019 18:30:08 +0200, >Ranjani Sridharan wrote: >> >> On Wed, 2019-05-08 at 10:32 +0800, libin.yang@xxxxxxxxx wrote: >> > From: Libin Yang <libin.yang@xxxxxxxxx> >> > >> > If playback/capture is paused and system enters S3, after system >> > returns from suspend, BE dai needs to call prepare() callback when >> > playback/capture is released from pause if RESUME_INFO flag is not >> > set. >> Hi Takashi, >> >> This is a question for you. We've run into the problem of not being >> able to do a pause-release after the system resumes from S3 after we >> removed INFO_RESUME from the SOF driver. >> >> Apparently, with this flag removed, when the user does a pause release >> after resuming from S3, the prepare() callback gets invoked for the FE >> but doesnt happen for the the BE. Could you please guide us on whether >> this is the right approach and if not, suggest an alternative? I think this may be a ASoC FE-BE defect. In this case, ASoC will call FE dai prepare(), but it will not call BE dai prepare() because of the judgement. This is why I made the patch. > >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. I think our current solution is reasonable. we should remove INFO_RESUME for Intel platform. The only side effect is that we will restart the PCM. My understanding is that INFO_RESUME is used for those platforms which can support suspend/resume by hardware. And obviously, on intel platforms, we need do a lot of recovery for resume in driver. Regards, Libin > >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. > > >thanks, > >Takashi > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
