Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7035306imu; Thu, 31 Jan 2019 04:00:17 -0800 (PST) X-Google-Smtp-Source: ALg8bN4XePMs4691MqvbzGoSjYbN+i6h+fo1mPYVS0GTzuiFC19PtoHMw3DdJt/ln9WOaZDfDwFO X-Received: by 2002:a63:8441:: with SMTP id k62mr31019616pgd.392.1548936017014; Thu, 31 Jan 2019 04:00:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548936016; cv=none; d=google.com; s=arc-20160816; b=HNDNtFsUXalepwrog+PC1iW5tSaeZgReWeSJDodBFP7fUMOYGTw+ML1g0Yh27ExZ7/ BSTit6nrrxcU/H5ydEZ0apn82Tt8o7LeNig6ux7qgKlYiJ0iDXqAObNkc2s9LfpR6Z8n yDa8FRdy2eaJ04Ib6TXu+iOYRicKkveCQmZ+GA8JTGAMYRIISKKMPbDuSH+kSVNgcZ2Y pYF02TGKzjKvv/OG2b1hZ+CpklW8p4yDudK+AH+/utIvcYxb3RdHUST+lAm/K77e5Q/2 dO2Uj9Dyqg5KK2ymSUVxW8TjT4D0kWVsSi0HRwEr/5lGTuPrAmiGVp/xilrCFoSW/7Cr 4ufg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=P+uVLx8ScRm8eRY8PFzlCEmNSebHWAlypfqkhkOu3tE=; b=hJJvKp6s+1HtsN9QElfv7cjx+VJpgX5gHkAg8QdhqNvmnQcipk8Qa0nRfJtQegftLy wn4D6ZT+67FImHuLC8bYCdzP+1bbKi049dY+9lWKeM5NZXEd2O8Cbjl2K456u4RJOUtI FENPppaH6nIV2BjhUwHH0glPV6W4s198YV7rG/hgPSowOLE76BDlQNEA+C1DPTXfRuOg i2E2ESAYRab+0sHGuHdXQZQloRmgd887V6OTf8AoNLdBRUggEKpRJyjVJEAyv4h8SMNU 9V6aZE22aaAC8sGvNbmlmg8BvMYAsjGZh4kvr1L7WZrtibn+Cf5NFqRmFiIkiJNMO8cX 6ARw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a124si4464076pfb.263.2019.01.31.04.00.01; Thu, 31 Jan 2019 04:00:16 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732421AbfAaL7L (ORCPT + 99 others); Thu, 31 Jan 2019 06:59:11 -0500 Received: from mx2.suse.de ([195.135.220.15]:39788 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726153AbfAaL7K (ORCPT ); Thu, 31 Jan 2019 06:59:10 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6652EAC66; Thu, 31 Jan 2019 11:59:08 +0000 (UTC) Date: Thu, 31 Jan 2019 12:59:07 +0100 Message-ID: From: Takashi Iwai To: "Rafael J. Wysocki" Cc: Thierry Reding , "Rafael J. Wysocki" , Jon Hunter , Pierre-Louis Bossart , Sameer Pujar , Jaroslav Kysela , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , mkumard@nvidia.com, rlokhande@nvidia.com, sharadg@nvidia.com, Linux Kernel Mailing List , linux-tegra@vger.kernel.org, Linux PM Subject: Re: [PATCH v2] ALSA: hda/tegra: enable clock during probe In-Reply-To: References: <1548414418-5785-1-git-send-email-spujar@nvidia.com> <20190131110530.GA23438@ulmo> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > > > 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). Right now, we have a code like below, pushing the initialization in an async work and let the probe returning quickly. hda_tegra_probe() { .... 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. thanks, Takashi