From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E1D5CA9EB9 for ; Tue, 29 Oct 2019 05:34:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E811E2086A for ; Tue, 29 Oct 2019 05:34:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eK/lDdHG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E811E2086A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=spQ4x3BkiU6cdF3ArvOAqw4yY9wT6kUpr3BnPVCuQJY=; b=eK/lDdHGdw6k3L xQppEPVZMHNeCLC3B4Tn5AVXB9jl+ekz7gn/2U19PeLuWtUEFTIoq2IKaxwQLAlRLjXRZ7zpsaOAs EDeOS6RkyJ48p2CAdI5L0l0dIBIwl0AHO9MSEykoCj76uJCt/QTkzD5jsjcHXdIUlQoWc2a1Og5Lg KZkETBjsnX/ESK5cLpKfudaqXjop4yQb/4YeL7gtPVL330CmbklFR+WzxAtA6UJY80FJa3+Dk2jCC H7sY9LTIDfaH4yketrI9VhBGdmcB6V/b4Ukgxr92glWIRteVc1KTRgmTjI2y9hdkjho71DLSs7SWv qhMBgG+/xnRKK2QzCF8A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iPK9Y-0001P9-Bg; Tue, 29 Oct 2019 05:34:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iPK9U-0001OV-ME for linux-arm-kernel@lists.infradead.org; Tue, 29 Oct 2019 05:34:46 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 061971F1; Mon, 28 Oct 2019 22:34:41 -0700 (PDT) Received: from e107533-lin.cambridge.arm.com (e107533-lin.shanghai.arm.com [10.169.109.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3FE2F3F71F; Mon, 28 Oct 2019 22:37:26 -0700 (PDT) Date: Tue, 29 Oct 2019 13:34:24 +0800 From: Sudeep Holla To: Ulf Hansson Subject: Re: [PATCH 10/13] cpuidle: psci: Add a helper to attach a CPU to its PM domain Message-ID: <20191029053414.GA4481@e107533-lin.cambridge.arm.com> References: <20191010113937.15962-1-ulf.hansson@linaro.org> <20191010113937.15962-11-ulf.hansson@linaro.org> <20191024163117.GB22036@bogus> <20191027023023.GC18111@e107533-lin.cambridge.arm.com> <20191028074905.GA27884@e107533-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191028_223444_820367_7F9EADCD X-CRM114-Status: GOOD ( 34.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Lorenzo Pieralisi , Linux PM , Stephen Boyd , linux-arm-msm , Daniel Lezcano , "Rafael J . Wysocki" , Lina Iyer , Bjorn Andersson , Kevin Hilman , Rob Herring , Sudeep Holla , Niklas Cassel , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Oct 28, 2019 at 10:45:22AM +0100, Ulf Hansson wrote: > + Niklas > > On Mon, 28 Oct 2019 at 08:49, Sudeep Holla wrote: > > > > On Mon, Oct 28, 2019 at 08:35:55AM +0100, Ulf Hansson wrote: > > > On Sun, 27 Oct 2019 at 03:30, Sudeep Holla wrote: > > > > > > > > On Thu, Oct 24, 2019 at 06:47:43PM +0200, Ulf Hansson wrote: > > > > > On Thu, 24 Oct 2019 at 18:31, Sudeep Holla wrote: > > > > > > > > > > > > On Thu, Oct 10, 2019 at 01:39:34PM +0200, Ulf Hansson wrote: > > > > > > > Introduce a PSCI DT helper function, psci_dt_attach_cpu(), which takes a > > > > > > > CPU number as an in-parameter and tries to attach the CPU's struct device > > > > > > > to its corresponding PM domain. > > > > > > > > > > > > > > Let's makes use of dev_pm_domain_attach_by_name(), as it allows us to > > > > > > > specify "psci" as the "name" of the PM domain to attach to. Additionally, > > > > > > > let's also prepare the attached device to be power managed via runtime PM. > > > > > > > > > > > > > > Signed-off-by: Ulf Hansson > > > > > > > --- > > > > > > > drivers/cpuidle/cpuidle-psci-domain.c | 21 +++++++++++++++++++++ > > > > > > > drivers/cpuidle/cpuidle-psci.h | 6 ++++++ > > > > > > > 2 files changed, 27 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c > > > > > > > index 3f5143ccc3e0..7429fd7626a1 100644 > > > > > > > --- a/drivers/cpuidle/cpuidle-psci-domain.c > > > > > > > +++ b/drivers/cpuidle/cpuidle-psci-domain.c > > > > > > > @@ -9,9 +9,11 @@ > > > > > > > > > > > > > > #define pr_fmt(fmt) "CPUidle PSCI: " fmt > > > > > > > > > > > > > > +#include > > > > > > > #include > > > > > > > #include > > > > > > > #include > > > > > > > +#include > > > > > > > #include > > > > > > > #include > > > > > > > #include > > > > > > > @@ -279,3 +281,22 @@ static int __init psci_idle_init_domains(void) > > > > > > > return ret; > > > > > > > } > > > > > > > subsys_initcall(psci_idle_init_domains); > > > > > > > + > > > > > > > +struct device *psci_dt_attach_cpu(int cpu) > > > > > > > +{ > > > > > > > + struct device *dev; > > > > > > > + > > > > > > > + /* Currently limit the hierarchical topology to be used in OSI mode. */ > > > > > > > + if (!psci_has_osi_support()) > > > > > > > + return NULL; > > > > > > > + > > > > > > > + dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), "psci"); > > > > > > > > > > > > This clarifies the need for the fixed name. But why not just go by index 0 > > > > > > as the consumer of these psci power-domains will have only one power domain > > > > > > entry. Why do we need this name compulsory ? > > > > > > > > > > The idea is to be future proof. If I recall correctly, the CPU node on > > > > > some QCOM SoCs may also have "CPR" PM domain specified, thus > > > > > "multiple" power-domains could be specified. > > > > > > > > > > > > > I am sure we don't want to mx-n-match any power domain provider with > > > > psci. And also I expect in these above mentioned cases, there won't be any > > > > psci power domains. > > > > > > > > > In any case, using "psci" doesn't really hurt, right? > > > > > > > > > > > > > Doesn't but I don't see need for one as only one should exist, as mentioned > > > > above we don't want mix-n-match with psci ever. > > > > > > Not sure I get your point, sorry. > > > > > > The CPU could very well be attached to more than one power-domain. Of > > > course not multiple "PSCI power-domains". One could be an PSCI power > > > domain and another one could be the QCOM CPR (Core power reduction) > > > power domain. > > > > > > > And who controls QCOM CPR ? If it's OSPM, this model is broken. > > I mean OSPM can vote, but the control *has* to be in PSCI firmware to > > change any CPU power state. > > > > If it's firmware controlled, then there's no need to explicitly specify > > both to OSPM. > > This is about OPP and CPUFreq, so it has nothing to do with PSCI. > > > > > > Have a look at these binding, there are already upstream, perhaps that > > > clarifies this? > > > Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt > > > > > > > OK, I will have a look. > > Great. > > I have looped in Niklas Casell, he should be able to answer any more > detailed questions in regards to QCOM CPR, if that is needed. > So had a look at the DT bindings and standalone it looks fine. But when it's mixed like the way you describe: yikes! Why does a power(oh wait it's actually performance domain!) is combined with a device whose actual power is controlled by only by PSCI/firmware is associated along with another power(again actally performance) domain. This whole representation of performance domain as power domain in the bindings is a *mess*. If Linux kernel chose to implement it as part of genpd, that's fine. But we should have had a separate binding for that. > In any case, we are discussing whether we should require a > power-domain-names set to "psci" for the CPU node - and I don't see > how that could hurt. Right? > Honestly I don't like this, but we don't have any choice I think. So yes, but you need to update the binding. Hope new platform move all these performance domain control part into firmware and have single control from kernel unlike the present generation which OPP through clock or cpufreq and the voltage/performance comtrol via genpd. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel