Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4924748ima; Tue, 5 Feb 2019 03:40:59 -0800 (PST) X-Google-Smtp-Source: AHgI3IZw4M9c4wqLMpmMFhtUNRlKvhBJjt6PRgDL0F94pwZJwCDexeSXqhPK43NotbKlJZX5MCEW X-Received: by 2002:a63:200c:: with SMTP id g12mr4135090pgg.53.1549366859301; Tue, 05 Feb 2019 03:40:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549366859; cv=none; d=google.com; s=arc-20160816; b=mudpsBJBP7XwEbktvX74sT7HSMnXKi6ukjjstQpxC1xn1cWngqUQSTAyqbhy280l9n sZ1qfO/Pl1jQq8v2soI4qwycXbRfxEhTMi0DzXp3MpXD6v8sxyeXDHkWsjE1ulcci2gh TZIc2lWj6zjPcQtSsGb/zj5H65rVd68rTdca1NEGvqTfJaFMAFw3qKnG0vc7Xj0W1Mx1 kU0jreIvnRuAse7bEdOUHowp8MXOa7gzhVqWiGMt8jeHPBGcWALB4wGUC7Y5YhXVoz0M Fa3IxLDWwEJdZ8rY9SVT4pKnBDUL3tHJQ8DjUZ6tBNsMr+R95CL2O0Y/Vh0QUjFI0CUo mlOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=y3p52e/qwTn0sErAn2RAhwr/bi+t0QZgFf79PoMxNpc=; b=Nw1jtlQSvwbi48Vc7FHcA7TSFRgv7cPYJEHvwkr/aBnZuT8njXdLi0jkuEx+pocM+u 6+tLknQG97gUb8IDOLm9U+1Qzd+PKBzbiBz4xbmGlItidyoSoT2SmDet+EEORdSLrC1o I+QDcgBUIojVjxAIFjTnARO40XFnLxuZK5Z61801V+YRolDJZIaaWCkR2yBTwYYB2Rze swh0F6Uz8fMgLP0nXNC5ubJzDt0PgmCtze/WBSUwc4BSOA357B/dW+9cf9pH/3ELrJHF oxBNnCjMed4SZJRfffJcjwadSH7zx8cFS3ltttFnM4xTMxob9TldptkkRg7cSWou9Dqc tTQA== 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 s123si3187637pfb.274.2019.02.05.03.40.43; Tue, 05 Feb 2019 03:40:59 -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 S1728889AbfBELgA (ORCPT + 99 others); Tue, 5 Feb 2019 06:36:00 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:53884 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727039AbfBELf7 (ORCPT ); Tue, 5 Feb 2019 06:35:59 -0500 Received: from 79.184.254.36.ipv4.supernova.orange.pl (79.184.254.36) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.183) id 56376d4980eb645e; Tue, 5 Feb 2019 12:35:57 +0100 From: "Rafael J. Wysocki" To: Jon Hunter Cc: Sameer Pujar , Thierry Reding , "Rafael J. Wysocki" , Takashi Iwai , Pierre-Louis Bossart , 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 Date: Tue, 05 Feb 2019 12:34:46 +0100 Message-ID: <4564414.Hi6AUZdI4M@aspire.rjw.lan> In-Reply-To: <80a45aa3-8a22-959c-0c73-03ad2d6b1f8c@nvidia.com> References: <1548414418-5785-1-git-send-email-spujar@nvidia.com> <80a45aa3-8a22-959c-0c73-03ad2d6b1f8c@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 Monday, February 4, 2019 11:04:50 AM CET Jon Hunter wrote: > > On 04/02/2019 08:16, Sameer Pujar wrote: > > ... > > > Objective is to have things working with or without CONFIG_PM enabled. > > From previous comments and discussions it appears that there is mixed > > response > > for calling hda_tegra_runtime_resume() or runtime PM APIs in probe() > > call. Need > > to have consensus regarding the best practice to be followed, which > > would eventually > > can be used in other drivers too. > > > > Rafael is suggesting to use CONFIG_PM check to do manual setup or > > runtime PM setup in probe, > > which would bring back the earlier above mentioned concern. > > > > if (IS_ENABLED(CONFIG_PM)) { > > do setup based on pm-runtime > > } else { > > do manual setup > > } > > Both if/else might end up doing the same here. > > Do we really need CONFIG_PM check here? > > > > Instead does below proposal appear fine? > > > > probe() { > > hda_tegra_enable_clock(); > > } > > > > probe_work() { > > /* hda setup */ > > . . . > > pm_runtime_set_active(); /* initial state as active */ > > pm_runtime_enable(); > > return; > > } > > I believe that this still does not work, because if there is a > power-domain that needs to be turned on, this does not guarantee this. > So I think that you need to call pm_runtime_get ... > > probe() { > if (!IS_ENABLED(CONFIG_PM)) > hda_tegra_enable_clock(); > } > But alas, there are no PM domains with CONFIG_PM unset. CONFIG_PM unset means that the *driver* has to know how to turn on the device and that has to be sufficient. Which basically is my point when I'm saying that this information is not available to the core and it cannot do anything to handle this case without the extra knowledge. Thanks, Rafael