From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ranjani Sridharan Subject: Re: [PATCH V2] ASoC: soc-pcm: BE dai needs prepare when pause release after resume Date: Thu, 09 May 2019 09:56:12 -0700 Message-ID: References: <1557282761-26146-1-git-send-email-libin.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 53932F89674 for ; Thu, 9 May 2019 18:56:16 +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: Takashi Iwai 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 > 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