Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7216366imu; Thu, 31 Jan 2019 06:52:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN4b6q7shZco0YT/hr4Dl8CgE9H5iZus/GzN9q0hJBo4Vjb1wHI4u1MUdaoFho5yhl3CkH8C X-Received: by 2002:a63:b543:: with SMTP id u3mr31585340pgo.420.1548946361375; Thu, 31 Jan 2019 06:52:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548946361; cv=none; d=google.com; s=arc-20160816; b=jN9ua0cpf4TxixhCxHsNFrmGAEgWGx6gRpZmG4iAz9jTs5dNDWJ2GRH9Qz/7fYZLYr EjA4sX1gGAiNoS48HPN4FYQ/EGF7MTROVLldqvK1xrVcyaLeA8w7nRQM6J+NH/WeKAHs 3oafT/GBlM0wmURRYjKJR0+8Hw4P9RI+ZEmwq2k+kv+2rtnDQpF1q4DUybP5+qqJgMl4 3gX/V9laCXUAWTQXdUhsd5k0CVkhdQglaPDJSUYFCLfZy4R0kZQKSAyVG2fcZaHOVU+7 XCbXEFIfAPUZfgfrrJQIXcEJbS/hf4fsSqTfKOQlxLPAPvvngMU/S1PMuf8+/X7NrNy4 C2gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=njYyIG6apH9x6+J88NDrmgbazHY3VwxJaHqQG8RunUc=; b=hsEGb5m5HNN+4XZ3YaOGWW4se+yxsX+OHwO1gQSaIHekG7F7x5O/BK4ZRqBAiu8xmG zRCAjs9+Q7RyDchFSfnjqmCKuMFicQiCg+5IsHjTTHQEPaneUmeFl48vVc6FtjehvKS5 RfuTbGQC7nIpyeP+6FzGxQA8hytDOfMZkmXGzOhakLPGxCfr6jQI1oMLX8U47VG2Pv3m +aqIyLLkPGK9gvESnqJaXX6ZpNJ8uNjdLbVF56zjm4w08kc6/nSQoafcZd2EjuF4MRNx f/CAOCuHgxaKaKZGA/pT7zp/VJoS0jAUoBGjZGXwwsaNp3r09Hgbl8WoxSXil+C4ahYG WnHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=l6wA7czb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c7si2061364plz.118.2019.01.31.06.51.49; Thu, 31 Jan 2019 06:52:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=l6wA7czb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732186AbfAaOVq (ORCPT + 99 others); Thu, 31 Jan 2019 09:21:46 -0500 Received: from hqemgate16.nvidia.com ([216.228.121.65]:16984 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727035AbfAaOVq (ORCPT ); Thu, 31 Jan 2019 09:21:46 -0500 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 31 Jan 2019 06:21:03 -0800 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Thu, 31 Jan 2019 06:21:44 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Thu, 31 Jan 2019 06:21:44 -0800 Received: from [10.25.75.21] (172.20.13.39) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 14:21:38 +0000 Subject: Re: [PATCH v2] ALSA: hda/tegra: enable clock during probe To: "Rafael J. Wysocki" , Takashi Iwai CC: Thierry Reding , "Rafael J. Wysocki" , Jon Hunter , Pierre-Louis Bossart , Jaroslav Kysela , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , , , , Linux Kernel Mailing List , , Linux PM References: <1548414418-5785-1-git-send-email-spujar@nvidia.com>

<20190131110530.GA23438@ulmo>

From: Sameer Pujar Message-ID: Date: Thu, 31 Jan 2019 19:51:34 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL101.nvidia.com (172.20.187.10) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1548944463; bh=njYyIG6apH9x6+J88NDrmgbazHY3VwxJaHqQG8RunUc=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Transfer-Encoding: Content-Language; b=l6wA7czbXspX6fISgbXPcDGsKMziBKLD8KkRrVTz7WLZHJM557eNsRLsTPhglM5pO ugoMGmT4phEhQ0m6SDJyp2Ibpps2p5HNqwWsgDDAj1pWT/YuCP6B5T9rlQEYH5yGmO kPqS3gO34Nitk1p4tDyLCw7blA0nUw28A+DmMIs7iSq0vyIB+AA4i5CXZBcjVutQlR Gll4vTKb/GnJVSaYYwTVEreISPRkZB/yX+q95OaQ6ZRiSg5VxO1Wx35mfw8k8xGkGI DPhMxFGY7MCTSIPrGnyFCuuv9dIPK1OlFhcA/4YrTq7gnz7zAutI7UK7cUYIzc6oBN WSYocvcqYRw9A== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/31/2019 5:40 PM, Rafael J. Wysocki wrote: > On Thu, Jan 31, 2019 at 12:59 PM Takashi Iwai wrote: >> On Thu, 31 Jan 2019 12:46:54 +0100, >> Rafael J. Wysocki wrote: >>> On Thu, Jan 31, 2019 at 12:21 PM Takashi Iwai wrote: >>>> On Thu, 31 Jan 2019 12:05:30 +0100, >>>> Thierry Reding wrote: >>>>> On Wed, Jan 30, 2019 at 05:40:42PM +0100, Takashi Iwai wrote: >>> [cut] >>> >>>>>> If I understand correctly the code, the pm domain is already activated >>>>>> at calling driver's probe callback. >>>>> As far as I can tell, the domain will also be powered off again after >>>>> probe finished, unless the device grabs a runtime PM reference. This is >>>>> what happens via the dev->pm_domain->sync() call after successful probe >>>>> of a driver. >>>> Ah, a good point. This can be a problem with a probe work like this >>>> case. Are you suggesting, whether runtime PM is enabled/disabled, after successful probe the domain would be powered off? For CONFIG_PM enabled case, probe() can call get_sync() and put_sync() can be in probe_work. How this needs to be handled for CONFG_PM disabled case? (just calling clock_enable() may not be sufficient as per previous comments) >>>>> It seems to me like it's not a very well defined case what to do when a >>>>> device needs to be powered up but runtime PM is not enabled. >>>>> >>>>> Adding Rafael and linux-pm, maybe they can provide some guidance on what >>>>> to do in these situations. >>>>> >>>>> To summarize, what we're debating here is how to handle powering up a >>>>> device if the pm_runtime infrastructure doesn't take care of it. Jon's >>>>> proposal here was, and we use this elsewhere, to do something like this: >>>>> >>>>> pm_runtime_enable(dev); >>>>> if (!pm_runtime_enabled(dev)) { >>>>> err = foo_runtime_resume(dev); >>>>> if (err < 0) >>>>> goto fail; >>>>> } >>>>> >>>>> So basically when runtime PM is not available, we explicitly "resume" >>>>> the device to power it up. >>>>> >>>>> It seems to me like that's a fairly common problem, so I'm wondering if >>>>> there's something that the runtime PM core could do to help with this. >>>>> Or perhaps there's already a way to achieve this that we're all >>>>> overlooking? >>>>> >>>>> Rafael, any suggestions? >>>> If any, a common helper would be appreciated, indeed. >>> I'm not sure that I understand the problem correctly, so let me >>> restate it the way I understand it. >>> >>> What we're talking about is a driver ->probe() callback. Runtime PM >>> is disabled initially and the device is off. It needs to be powered >>> up, but the way to do that depends on some configuration of the board >>> etc., so ideally >>> >>> pm_runtime_enable(dev); >>> ret = pm_runtime_resume(dev); >>> >>> should just work, but the question is what to do if runtime PM doesn't >>> work as expected. That is, CONFIG_PM_RUNTIME is unset? Or something >>> else? >> Yes, the question is how to write the code for both with and without >> CONFIG_PM (or CONFIG_PM_RUNTIME). > This basically is about setup, because after that point all should > just work in both cases. > > Personally, I would do > > if (IS_ENABLED(CONFIG_PM)) { > do setup based on pm-runtime > } else { > do manual setup > } do we really need config check here? The debate was, whether to call hda_tegra_runtime_resume() or hda_tegra_enable_clocks() unconditionally here. It would take care of both CONFIG_PM enabled/disabled cases. Then enable runtime PM. >> Right now, we have a code like below, pushing the initialization in an >> async work and let the probe returning quickly. >> >> hda_tegra_probe() { >> .... > So why don't you do > > if (!IS_ENABLED(CONFIG_PM)) { > do manual clock setup > } > > here? > >> pm_runtime_enable(); >> schedule_work(); >> return; >> } >> >> hda_tegra_probe_work() { >> pm_runtime_get_sync(); >> .... >> pm_runtime_put_sync(); >> } >> >> Then it truned outhis code lacks of the clock initialization when >> runtime PM isn't enabled. Normally it's done via runtime resume >> >> hda_tegra_runtime_resume() { >> hda_tegra_enable_clocks(); >> .... >> } >> >> And now the question is what is the standard idiom in such a case. >> >> IMO, calling pm_runtime_resume() inside the probe function looks >> weird, and my preference was to initialize the clocks explicitly, then >> enable runtime PM. But if using pm_runtime_resume() in the proc >> should be seen as a standard procedure, I'm fine with that. I think reference here is, whether calling hda_tegra_runtime_resume() in probe() is a standard procedure or not. > Well, people do pm_runtime_resume() in ->probe() too, but > pm_runtime_resume() returns 1 for CONFIG_PM unset, so that won't give > you what you want anyway. :-) > > Cheers, > Rafael