From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH V2] ASoC: soc-pcm: BE dai needs prepare when pause release after resume Date: Thu, 09 May 2019 19:35:17 +0200 Message-ID: References: <1557282761-26146-1-git-send-email-libin.yang@intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 96AD1F8073C for ; Thu, 9 May 2019 19:35:18 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Ranjani Sridharan Cc: libin.yang@intel.com, alsa-devel@alsa-project.org, ranjani.sridharan@intel.com, pierre-louis.bossart@linux.intel.com, rander.wang@intel.com, broonie@kernel.org List-Id: alsa-devel@alsa-project.org On Thu, 09 May 2019 18:56:12 +0200, Ranjani Sridharan wrote: > > > 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. 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. thanks, Takashi