From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: ASoC updates for v4.2 Date: Mon, 22 Jun 2015 13:24:02 +0200 Message-ID: References: <20150622092616.GN14071@sirena.org.uk> <20150622103034.GQ14071@sirena.org.uk> 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 mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 5AED6261B19 for ; Mon, 22 Jun 2015 13:24:03 +0200 (CEST) In-Reply-To: <20150622103034.GQ14071@sirena.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: alsa-devel@alsa-project.org, Koro Chen , Liam Girdwood List-Id: alsa-devel@alsa-project.org At Mon, 22 Jun 2015 11:30:34 +0100, Mark Brown wrote: > > On Mon, Jun 22, 2015 at 11:58:24AM +0200, Takashi Iwai wrote: > > > In addition to rsnd-card.c, I get a compile warning as below: > > > sound/soc/mediatek/mtk-afe-pcm.c:1035:12: warning: 'mtk_afe_runtime_suspend' defined but not used [-Wunused-function] > > > And, looking at the code, it seems calling runtime suspend in the > > following way at probe: > > > pm_runtime_enable(&pdev->dev); > > if (!pm_runtime_enabled(&pdev->dev)) { > > ret = mtk_afe_runtime_resume(&pdev->dev); > > if (ret) > > goto err_pm_disable; > > } > > I'm confused, where's the call to runtime suspend? It's in static const struct dev_pm_ops mtk_afe_pm_ops = { SET_RUNTIME_PM_OPS(mtk_afe_runtime_suspend, mtk_afe_runtime_resume, NULL) }; But my concern above isn't about the warning itself. I just stumbled on the code invoking runtime resume while looking at this warning, and wondered the behavior with CONFIG_PM=n. Usually this kind of warning could be simply fixed by adding a proper ifdef. But, this driver calls runtime resume in the probe manually. > > I'm not sure whether this really behaves correctly, especially when a > > kernel is built without CONFIG_PM. > > Could you be more specific about the problem you're seeing? If runtime > PM is disabled pm_runtime_enabled() will return false and we'll run > through the resume path during probe() instead, otherwise we'll runtime > resume whenever we need to use the hardware. The runtime suspend is never called when CONFIG_PM=n. OTOH, we call runtime resume *always* at probe when CONFIG_PM=n. This looks inconsistent to me. If it's a part of the mandatory initialization, it should be named explicitly so, and make the runtime resume callback just calls it instead. Takashi