Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp5241381pxv; Tue, 6 Jul 2021 22:05:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoY+ShG5OssLPhnXE8IYOmJvEgHku4lp23mRgob/L+zSQbYtIM78VokhW/d9Yt+7UT4Bm8 X-Received: by 2002:a05:6402:28a1:: with SMTP id eg33mr27533007edb.249.1625634332468; Tue, 06 Jul 2021 22:05:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625634332; cv=none; d=google.com; s=arc-20160816; b=LgtkKbC+OCgJ5o7BU0iYnJsIxyLhGAebqywgiAp3p0MVgJJYampvk2K8MaKnBhvFkj ycohI1CL1Zevv6xRYGErNdXynBIg+gC6BbZyFK3uwkXFhezGAKwXmfvF05eTKz45OrE2 6bw0CqiGdKzYruUc7T+99zgb8vw0CNTZWb9Y3s5FLLue8CdwFupcnQtMo74g0eJXrhJu 08JkKEw2mpvs8WtuLnX6/9xieCFD7OYJh/WydVWP3h3I4Gj/tIOjqa87yxjwYFOBMnmP ADJ7cAVMy4lQmRG/4+fTvJ81eNNaZJoIn5ATbMWgjDR1KIo0uisf9D5DEo7ot6q463yV cfEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZwJ6LzMYt92aA7ipQ1QaHUSOYNKd4HK3usxDJ6K7NKM=; b=RLDnEKf3xO7JiZs8DsvwkiDJQV00RonNOTIq7fDP7ugoKY0Et1liTB1R4W3OZxxTLL YL5DUVqOcPVwN9RZeabTqrEmTxkQjvD4lS9wnaFhC8O8koeOLqyb5DyfKXDCnS/s9Iob thMN89UtQ1WSKERqmHrFJlzpjsKK0l52UIfo8gkq13o2OLDI2XSYOBDFungj5qw5FlJK c7yLmwmHhyItEgvX0y4y5OzSXJ1ngveNXtpgAOLbYNXl+W4pENMvYhnutdVSd6J5PpEP 7es0IZP98Hhq7TrjtIjLptWpoLgm5uAPsI+7aL1U3Jx14frF92gvGH5kLrOALKEU+ftQ nb3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PGN9NdUn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr2si6687394ejc.245.2021.07.06.22.05.09; Tue, 06 Jul 2021 22:05:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PGN9NdUn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230120AbhGGFGu (ORCPT + 99 others); Wed, 7 Jul 2021 01:06:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230139AbhGGFGs (ORCPT ); Wed, 7 Jul 2021 01:06:48 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C4C9C061762 for ; Tue, 6 Jul 2021 22:04:02 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id m3so2005872oig.10 for ; Tue, 06 Jul 2021 22:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZwJ6LzMYt92aA7ipQ1QaHUSOYNKd4HK3usxDJ6K7NKM=; b=PGN9NdUnXnCAdb8kuPDg2/8BBx3g2U09UWEkOuU3CoaeWRP2zV9wavZF+QlJHnjCWK 7HLqF4HNg71I5OGbiu9dLgiu0i8/zjXgOATD3gf8YD8G1vSsat8s7UKoIEq9A1fOAO54 Sm9M8PbYlkiVOXEC1yQCaW1UpO7ZSUpZ7KDt55DFT03M5jLcvy5pYR4bfU3pMhIb0w/W oMTlA97aDAUjTs93SdusWlCB6Uu16surdUd/MIut0z56PbmGlAcy6d8yJYMEDMfpbdp0 OLv6VJt/T1SyHT9HgxNmgjuSE9LolYJDGSyq3QylDdCsqSEbvRPpWRjGfsRF2+PhKjSY cM+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZwJ6LzMYt92aA7ipQ1QaHUSOYNKd4HK3usxDJ6K7NKM=; b=B7Ooum9oykq8VaVblYCjpgUAAuFE/GFOp3i+wM2xWk/hI30CcRdWDY9hi7Y+qg9HW+ Q7NDc5EdHxL9jWv6syLxtqzez4dtbtAXChI/FOiQeicbb9eJs/5pC468JvH7oLHsR4Nf ppf7ruvfNOYZdsxPFSBKOVvZm3u7o6aUxJ8CIo3YQ3FaMGNr98NM0mGqiWkRtCIHTMSo VSriZIA47UJsxXTl30/yhjQSNDkMzRgVsqq+JPZEx0puetk28/XQpg10Td+PKpbRYrhD WOmZERecXfPWsJD7GoL+E7X6Xol4gdZtdSwd/dXhaGNfsJ4V6MiK8mQXP6sf991H4Res sM+A== X-Gm-Message-State: AOAM533CEhtHmO5esADDQz1iQE9qDtPOL9QXCBap5h+kawAWV7ewuxJh 0A+Zg0czm7owHlHoP9Df4kgwfA== X-Received: by 2002:aca:4b43:: with SMTP id y64mr2905391oia.176.1625634241482; Tue, 06 Jul 2021 22:04:01 -0700 (PDT) Received: from yoga (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id r186sm3899058oia.6.2021.07.06.22.03.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jul 2021 22:04:00 -0700 (PDT) Date: Wed, 7 Jul 2021 00:03:58 -0500 From: Bjorn Andersson To: Ulf Hansson Cc: Dmitry Baryshkov , Andy Gross , Rob Herring , Stephen Boyd , Taniya Das , Jonathan Marek , Michael Turquette , linux-arm-msm , DTML , linux-clk , Bryan O'Donoghue , Mark Brown , Linux Kernel Mailing List Subject: Re: [PATCH 1/6] dt-bindings: clock: qcom,dispcc-sm8x50: add mmcx power domain Message-ID: References: <20210630133149.3204290-1-dmitry.baryshkov@linaro.org> <20210630133149.3204290-2-dmitry.baryshkov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 06 Jul 02:23 CDT 2021, Ulf Hansson wrote: > On Thu, 1 Jul 2021 at 21:26, Bjorn Andersson wrote: > > > > On Thu 01 Jul 11:58 CDT 2021, Ulf Hansson wrote: > > > > > On Thu, 1 Jul 2021 at 18:39, Dmitry Baryshkov > > > wrote: > > > > > > > > On Thu, 1 Jul 2021 at 19:17, Ulf Hansson wrote: > > > > > > > > > > On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov > > > > > wrote: > > > > > > > > > > > > On sm8250 dispcc requires MMCX power domain to be powered up before > > > > > > clock controller's registers become available. For now sm8250 was using > > > > > > external regulator driven by the power domain to describe this > > > > > > relationship. Switch into specifying power-domain and required opp-state > > > > > > directly. > > > > > > > > > > > > Signed-off-by: Dmitry Baryshkov > > > > > > --- > > > > > > .../bindings/clock/qcom,dispcc-sm8x50.yaml | 19 +++++++++++++++++++ > > > > > > 1 file changed, 19 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml > > > > > > index 0cdf53f41f84..48d86fb34fa7 100644 > > > > > > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml > > > > > > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml > > > > > > @@ -55,6 +55,16 @@ properties: > > > > > > reg: > > > > > > maxItems: 1 > > > > > > > > > > > > + power-domains: > > > > > > + description: > > > > > > + A phandle and PM domain specifier for the MMCX power domain. > > > > > > + maxItems: 1 > > > > > > + > > > > > > > > > > Should you perhaps state that this is a parent domain? Or it isn't? > > > > > > > > > > Related to this and because this is a power domain provider, you > > > > > should probably reference the common power-domain bindings somewhere > > > > > here. Along the lines of this: > > > > > > > > > > - $ref: power-domain.yaml# > > > > > > > > > > As an example, you could have a look at > > > > > Documentation/devicetree/bindings/power/pd-samsung.yaml. > > > > > > > > I'll take a look. > > > > > > > > > > > > > > > + required-opps: > > > > > > + description: > > > > > > + Performance state to use for MMCX to enable register access. > > > > > > + maxItems: 1 > > > > > > > > > > According to the previous discussions, I was under the assumption that > > > > > this property belongs to a consumer node rather than in the provider > > > > > node, no? > > > > > > > > It is both a consumer and a provider. It consumes SM8250_MMCX from > > > > rpmhpd and provides MMSC_GDSC. > > > > > > That sounds a bit weird to me. > > > > > > > dispcc is a hardware block powered by MMCX, so it is a consumer of it > > and needs to control MMCX. > > Right, that sounds reasonable. > > > > > > In my view and per the common power domain bindings (as pointed to > > > above): If a power domain provider is a consumer of another power > > > domain, that per definition means that there is a parent domain > > > specified. > > > > > > > And in addition to needing MMCX to access the dispcc, the exposed > > power-domain "MDSS_GDSC" is powered by the same MMCX and as such > > MDSS_GDSC should be a subdomain of MMCX. > > What do you mean by "exposed"? It sounds like you are saying that > "MDSS_GDSC" is an artificial power domain, no? > > If that's the case, more exactly, why is it like this? > > My apologies if I bother you with details, but as a maintainer of > genpd, it is very useful to me to have the complete picture. > The display hardware blocks are powered by the MDSS_GDSC power-domain, which is a subdomain to the MMCX power domain. MDSS_GDSC is controlled by registers in the display clock controller block, which is also powered by the MMCX power domain. Lastly the MMCX power domain is controlled through the RPMh, using the rpmhpd driver. As such, specifying MMCX as the power-domain for the dispcc block and making the dispcc driver use that same power-domain as parent for the MDSS_GDSC seems to accurately depict these relationships. Regards, Bjorn > > > > > > But what I was trying to say yesterday is that the power-domain property > > should be sufficient and that we shouldn't need to drive MMCX to a > > particular performance_state in order to access the registers. > > > > Then as clients make votes on clock rates that requires higher > > performance_state, they would describe this in their opp-tables etc. > > > > > > But without any performance_state requests, pd->corner will in > > rpmhpd_power_on() be 0 and as such powering on the power-domain won't > > actually do anything. Similarly dev_pm_genpd_set_performance_state(dev, > > 0) on an active power-domain from rpmhpd will turn it off. > > Yes, I noticed the patches you posted. Thanks for helping out here! > > > > > > > So the reason why Dmitry is adding the required-opps to the binding is > > to get rpmhpd to actually tell the hardware to turn on the power domain. > > And I don't think this is in accordance with the framework's > > expectations. > > I agree! > > > > > Regards, > > Bjorn > > Kind regards > Uffe