Message ID | 20230607124628.157465-10-ulf.hansson@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp332143rwl; Wed, 7 Jun 2023 05:51:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Z7Z3q5BPVNvfo4fAymrRriIie+K0a+8QRfi+1uTz+9RZNulst6gUgRi09+fH/fvQjuKey X-Received: by 2002:a17:90a:1950:b0:259:1812:c9f9 with SMTP id 16-20020a17090a195000b002591812c9f9mr1676381pjh.1.1686142281377; Wed, 07 Jun 2023 05:51:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686142281; cv=none; d=google.com; s=arc-20160816; b=ZJ15ftTM2NHuK2Tc/EA8VXhe6nmLsUJmBYFs/0SjRF3qri1XWao6mgAsaKsNaqY+mZ b4Lnf0bJAulC/VxCKdy4/luK7E+e2nZ9QKlMGB6H6S+9BurVmiEMDJC8/TBXcyEJzlcT xmPKyiqpIxlJ5CltuxF5QVmjyO1dytYP0R/2fmLK3BVBmOvb8JIYCzAfhY98Gu+K2zmE aSofWAZfvO9ef9+pT3+UkckQc5gscovdoEjDLmzv9xbsiMRqYYIBnHkffYvAi4qwiH3d PRF5bibfFrNlZKr1RN6ENLxc70LCJYYDSv5UVapdV8me83VfNgmMRd3xdBNPyI4tqyo5 bQrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=yEZ1VzAf/ewGDW/CO5YjzDFKyIheYAdlDwMj1VXqtFc=; b=Lj7oJbkL0szPsEbdRzQiOF5MwrohAsxOP7iconn+4w3ZBkxoU6SH0abJhPeGjGoDWd 6KMoKA/XxAe0uimvqZT08ibiDzIFE98x3mt8VSopC/Ai2kesBPK8xTBYHPFxZbgT/CFl TQWUHJjHKIii0aFiQRXXD+8HIOeHuA2W3nAca/f2QhlIem/G0eFdhtk+WGvewqEqk+90 HnjvtN/YX4ZGpw4t0gwiRUbkakuCDVQCe3+F6eReS2Ai+jRgY7iH8bLLvR7Da4BLw5vy WaSZLpteccobkHjufyEXHkFNpOuy442SvblKd5YajxtTKJfgPqQeGifp8lipTDM3Fl4U WE9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="nPt/QsfP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m6-20020a17090b068600b002590bf12fedsi1043650pjz.181.2023.06.07.05.51.06; Wed, 07 Jun 2023 05:51:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="nPt/QsfP"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S241103AbjFGMrf (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 08:47:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240603AbjFGMrN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 08:47:13 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D8701BD7 for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 05:47:07 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4f6454a21a9so524704e87.3 for <linux-kernel@vger.kernel.org>; Wed, 07 Jun 2023 05:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686142026; x=1688734026; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yEZ1VzAf/ewGDW/CO5YjzDFKyIheYAdlDwMj1VXqtFc=; b=nPt/QsfPsptDpzewzdY7leTqIaUAJpiotvO0q3HqPzfmRErlMhhkfRuG0nRMHSjLBO 8vmDV4DrC7wghEALhqJhenkRYBm34v31CKfmEpgJiwiIi7GfJf3cL/kE3o0RlgD/TDUx KcxT101ueVqqtxYh/wUrXE5us7BGYsrV4dO8K/ZyYDv5TmfZYumby23yLPpsi35zd/w3 YaUJoH9ZivYsDJ8dPmRiloUWxrAF2yVGnpoQJsnqrnE5G+Llf0CPgza1htQ37ekmWic2 xA1jjjIEwAG1d4WQsvi+lXv1itWcWXIMaoECCjoWdh0v0dj4x4bAMiQ9+UTNb6Ho1KcH 7r7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686142026; x=1688734026; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yEZ1VzAf/ewGDW/CO5YjzDFKyIheYAdlDwMj1VXqtFc=; b=bE4Ti1K4y43b0GqAygqWGPaaO9eRtejMe9COWSfUQGRUR9e8XVGdG2tjTroJ8pXKhC ogVvJ1QC4a8oDO+f0SuQWMFjmHzzKAoCiGQWftp8+XMHt8OsfeMzpaxWMfYW9yVbPmlg R5NrM44AyaOpTo55XEo0zbzOrdmbeFdvJzqJ2iAQt2lFd1atWnE9ftFTWDIYho2qNdei LewIUpzO+iYIA6jslCs6CI5fdJ08d3O0CuM+FMkrExElawiSQygUx7o0+KkaIlzMggcx 4NBYwbIkeWMT1N8H/hNk/1PomFa+2u2/LCa6DX8WXhFN1ZYkvdVsEYfDNRrFQngciOP0 jsDw== X-Gm-Message-State: AC+VfDy6t7Wp6jaxaUb+c8QfT3jhTl+nHUSus9ro38cO+ptx4h/mbPo3 4TdYIKoAg7F4NmCvag8RHHDxaQ== X-Received: by 2002:a05:6512:14b:b0:4f6:171e:48e with SMTP id m11-20020a056512014b00b004f6171e048emr1979036lfo.22.1686142026612; Wed, 07 Jun 2023 05:47:06 -0700 (PDT) Received: from uffe-tuxpro14.. (h-94-254-63-18.NA.cust.bahnhof.se. [94.254.63.18]) by smtp.gmail.com with ESMTPSA id z7-20020a19f707000000b004f4b3e9e0cesm1781708lfe.297.2023.06.07.05.47.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 05:47:06 -0700 (PDT) From: Ulf Hansson <ulf.hansson@linaro.org> To: Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org> Cc: Nikunj Kela <nkela@quicinc.com>, Prasad Sodagudi <psodagud@quicinc.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Ulf Hansson <ulf.hansson@linaro.org>, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, devicetree@vger.kernel.org Subject: [PATCH 09/16] dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13 Date: Wed, 7 Jun 2023 14:46:21 +0200 Message-Id: <20230607124628.157465-10-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230607124628.157465-1-ulf.hansson@linaro.org> References: <20230607124628.157465-1-ulf.hansson@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768048329108826674?= X-GMAIL-MSGID: =?utf-8?q?1768048329108826674?= |
Series |
arm_scmi/opp/dvfs: Add generic performance scaling support
|
|
Commit Message
Ulf Hansson
June 7, 2023, 12:46 p.m. UTC
The protocol@13 node is describing the performance scaling option for the
ARM SCMI interface, as a clock provider. This is unnecessary limiting, as
performance scaling is in many cases not limited to switching a clock's
frequency.
Therefore, let's extend the binding so the interface can be modelled as a
generic "performance domain" too. The common way to describe this, is to
use the "power-domain" bindings, so let's use that.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > The protocol@13 node is describing the performance scaling option for the > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > performance scaling is in many cases not limited to switching a clock's > frequency. > > Therefore, let's extend the binding so the interface can be modelled as a > generic "performance domain" too. The common way to describe this, is to > use the "power-domain" bindings, so let's use that. What's wrong with the performance-domain binding? > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Conor Dooley <conor+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > --- > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index 5824c43e9893..cff9d1e4cea1 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -145,8 +145,8 @@ properties: > '#clock-cells': > const: 1 > > - required: > - - '#clock-cells' > + '#power-domain-cells': > + const: 1 > > protocol@14: > $ref: '#/$defs/protocol-node' > -- > 2.34.1 >
On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > The protocol@13 node is describing the performance scaling option for the > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > performance scaling is in many cases not limited to switching a clock's > frequency. > > Therefore, let's extend the binding so the interface can be modelled as a > generic "performance domain" too. The common way to describe this, is to > use the "power-domain" bindings, so let's use that. > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Conor Dooley <conor+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > --- > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index 5824c43e9893..cff9d1e4cea1 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -145,8 +145,8 @@ properties: > '#clock-cells': > const: 1 > > - required: > - - '#clock-cells' I am yet to look at the patches, just looked at this binding changes for now. Won't this break compatibility with existing DTBs. IMO, this is strict no no, you can't drop #clock-cells. I wanted to add performance-domains here as alternative but decided to not as I knew you were working on this.
On Thu, 15 Jun 2023 at 01:00, Rob Herring <robh@kernel.org> wrote: > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > The protocol@13 node is describing the performance scaling option for the > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > performance scaling is in many cases not limited to switching a clock's > > frequency. > > > > Therefore, let's extend the binding so the interface can be modelled as a > > generic "performance domain" too. The common way to describe this, is to > > use the "power-domain" bindings, so let's use that. > > What's wrong with the performance-domain binding? In my opinion I think the performance-domain binding is superfluous. We already have plenty of power-domains that do performance scaling too - and they stick with the power-domain binding, as it's sufficient. That said, I would rather follow the defacto standard that has been used for many years in the kernel. Do you have a preference that we should stick to? Kind regards Uffe > > > > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: Conor Dooley <conor+dt@kernel.org> > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > --- > > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > index 5824c43e9893..cff9d1e4cea1 100644 > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > @@ -145,8 +145,8 @@ properties: > > '#clock-cells': > > const: 1 > > > > - required: > > - - '#clock-cells' > > + '#power-domain-cells': > > + const: 1 > > > > protocol@14: > > $ref: '#/$defs/protocol-node' > > -- > > 2.34.1 > >
On Thu, 15 Jun 2023 at 10:44, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > The protocol@13 node is describing the performance scaling option for the > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > performance scaling is in many cases not limited to switching a clock's > > frequency. > > > > Therefore, let's extend the binding so the interface can be modelled as a > > generic "performance domain" too. The common way to describe this, is to > > use the "power-domain" bindings, so let's use that. > > > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: Conor Dooley <conor+dt@kernel.org> > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > --- > > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > index 5824c43e9893..cff9d1e4cea1 100644 > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > @@ -145,8 +145,8 @@ properties: > > '#clock-cells': > > const: 1 > > > > - required: > > - - '#clock-cells' > > I am yet to look at the patches, just looked at this binding changes for now. > > Won't this break compatibility with existing DTBs. IMO, this is strict > no no, you can't drop #clock-cells. I wanted to add performance-domains > here as alternative but decided to not as I knew you were working on this. Thanks for reviewing! The point with the suggested change was to allow any kind of combination of using #clock-cells and/or #power-domain-cells. Honestly I didn't really know how to best express that in the binding, but maybe someone can help me out here? I think enforcing #clock-cells to be used is unnecessary. Making it optional should not break existing DTBs, right? Moreover, currently it seems to be only Juno that uses "protocol@13" and the "#clock-cells" (at least by looking at the DTSes in-kernel). So, I wonder if it's really such a big deal to update the DT bindings for "protocol@13" at this point, but I may not have the complete picture. Kind regards Uffe
On Thu, Jun 15, 2023 at 11:39:06AM +0200, Ulf Hansson wrote: > On Thu, 15 Jun 2023 at 10:44, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > > The protocol@13 node is describing the performance scaling option for the > > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > > performance scaling is in many cases not limited to switching a clock's > > > frequency. > > > > > > Therefore, let's extend the binding so the interface can be modelled as a > > > generic "performance domain" too. The common way to describe this, is to > > > use the "power-domain" bindings, so let's use that. > > > > > > Cc: Rob Herring <robh+dt@kernel.org> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > > Cc: Conor Dooley <conor+dt@kernel.org> > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > > --- > > > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > index 5824c43e9893..cff9d1e4cea1 100644 > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > @@ -145,8 +145,8 @@ properties: > > > '#clock-cells': > > > const: 1 > > > > > > - required: > > > - - '#clock-cells' > > > > I am yet to look at the patches, just looked at this binding changes for now. > > > > Won't this break compatibility with existing DTBs. IMO, this is strict > > no no, you can't drop #clock-cells. I wanted to add performance-domains > > here as alternative but decided to not as I knew you were working on this. > > Thanks for reviewing! > > The point with the suggested change was to allow any kind of > combination of using #clock-cells and/or #power-domain-cells. Honestly > I didn't really know how to best express that in the binding, but > maybe someone can help me out here? > Even I don't know exact details, but there are rules like if this property is present, some other property can't be there or something on the similar lines. I have vague idea/recollection from my previous experiments which probably was not needed then and hence I can't just point to any examples unless I go and search myself. > I think enforcing #clock-cells to be used is unnecessary. Making it > optional should not break existing DTBs, right? Correct. That is what I meant, it is either #clock-cells or #power-domain-cells > > Moreover, currently it seems to be only Juno that uses "protocol@13" > and the "#clock-cells" (at least by looking at the DTSes in-kernel). Yes only one that has upstream DTS changes, but for sure it is used on couple of other platforms. So for we are still far away from deprecate it but we can eventually once users of it are ready to use new binding. > So, I wonder if it's really such a big deal to update the DT bindings > for "protocol@13" at this point, but I may not have the complete > picture. > Yes it does break compatibility. Yes I know Juno is not a production platform, but associating DT with kernel change makes is hard to switch to older stable kernel versions without DT change which I really hate as I will be wondering which SCMI perf is not working with stable kernel few months down the line. So yes, we are not dropping the support for old bindings even if it just for Juno(though I am sure it is not the only one). I have spent time on such silly things when we were in the process of pushing these bindings initially upstream. I prefer not to repeat that. -- Regards, Sudeep
On Thu, 15 Jun 2023 at 15:30, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, Jun 15, 2023 at 11:39:06AM +0200, Ulf Hansson wrote: > > On Thu, 15 Jun 2023 at 10:44, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > > > The protocol@13 node is describing the performance scaling option for the > > > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > > > performance scaling is in many cases not limited to switching a clock's > > > > frequency. > > > > > > > > Therefore, let's extend the binding so the interface can be modelled as a > > > > generic "performance domain" too. The common way to describe this, is to > > > > use the "power-domain" bindings, so let's use that. > > > > > > > > Cc: Rob Herring <robh+dt@kernel.org> > > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > > > Cc: Conor Dooley <conor+dt@kernel.org> > > > > Cc: devicetree@vger.kernel.org > > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > > > --- > > > > Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > > index 5824c43e9893..cff9d1e4cea1 100644 > > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > > @@ -145,8 +145,8 @@ properties: > > > > '#clock-cells': > > > > const: 1 > > > > > > > > - required: > > > > - - '#clock-cells' > > > > > > I am yet to look at the patches, just looked at this binding changes for now. > > > > > > Won't this break compatibility with existing DTBs. IMO, this is strict > > > no no, you can't drop #clock-cells. I wanted to add performance-domains > > > here as alternative but decided to not as I knew you were working on this. > > > > Thanks for reviewing! > > > > The point with the suggested change was to allow any kind of > > combination of using #clock-cells and/or #power-domain-cells. Honestly > > I didn't really know how to best express that in the binding, but > > maybe someone can help me out here? > > > > Even I don't know exact details, but there are rules like if this > property is present, some other property can't be there or something > on the similar lines. I have vague idea/recollection from my previous > experiments which probably was not needed then and hence I can't just > point to any examples unless I go and search myself. I will figure it out, np! > > > I think enforcing #clock-cells to be used is unnecessary. Making it > > optional should not break existing DTBs, right? > > Correct. That is what I meant, it is either #clock-cells or > #power-domain-cells Should we allow both? Or maybe that is just confusing? In either case, I am converting the scmi cpufreq driver to cope with using #power-domain-cells too, as that is useful regardless I think. However, that's a separate series on top of $subject series. > > > > > Moreover, currently it seems to be only Juno that uses "protocol@13" > > and the "#clock-cells" (at least by looking at the DTSes in-kernel). > > Yes only one that has upstream DTS changes, but for sure it is used on > couple of other platforms. So for we are still far away from deprecate it > but we can eventually once users of it are ready to use new binding. Okay, let's discuss when to deprecate it, but let's do that later on. > > > So, I wonder if it's really such a big deal to update the DT bindings > > for "protocol@13" at this point, but I may not have the complete > > picture. > > > > Yes it does break compatibility. Yes I know Juno is not a production > platform, but associating DT with kernel change makes is hard to switch > to older stable kernel versions without DT change which I really hate as > I will be wondering which SCMI perf is not working with stable kernel few > months down the line. So yes, we are not dropping the support for old > bindings even if it just for Juno(though I am sure it is not the only one). > I have spent time on such silly things when we were in the process of > pushing these bindings initially upstream. I prefer not to repeat that. Okay, thanks for sharing the information. Let's simply follow the regular path of how we deal with deprecating DT bindings then. Kind regards Uffe
On Thu, Jun 15, 2023 at 3:11 AM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Thu, 15 Jun 2023 at 01:00, Rob Herring <robh@kernel.org> wrote: > > > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > > The protocol@13 node is describing the performance scaling option for the > > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > > performance scaling is in many cases not limited to switching a clock's > > > frequency. > > > > > > Therefore, let's extend the binding so the interface can be modelled as a > > > generic "performance domain" too. The common way to describe this, is to > > > use the "power-domain" bindings, so let's use that. > > > > What's wrong with the performance-domain binding? > > In my opinion I think the performance-domain binding is superfluous. > We already have plenty of power-domains that do performance scaling > too - and they stick with the power-domain binding, as it's > sufficient. IMO, power-domains should be for power islands which can be power gated. I know they are abused though. Of course, when things are hidden in firmware, you don't really know. A power-domain could be just a clock or a clock could be multiple physical clocks. > That said, I would rather follow the defacto standard that has been > used for many years in the kernel. Do you have a preference that we > should stick to? If power-domains are sufficient, then why do we have performance-domains? We need clear rules for when to use what. Rob
On Fri, 14 Jul 2023 at 19:15, Rob Herring <robh@kernel.org> wrote: > > On Thu, Jun 15, 2023 at 3:11 AM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Thu, 15 Jun 2023 at 01:00, Rob Herring <robh@kernel.org> wrote: > > > > > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > > > The protocol@13 node is describing the performance scaling option for the > > > > ARM SCMI interface, as a clock provider. This is unnecessary limiting, as > > > > performance scaling is in many cases not limited to switching a clock's > > > > frequency. > > > > > > > > Therefore, let's extend the binding so the interface can be modelled as a > > > > generic "performance domain" too. The common way to describe this, is to > > > > use the "power-domain" bindings, so let's use that. > > > > > > What's wrong with the performance-domain binding? > > > > In my opinion I think the performance-domain binding is superfluous. > > We already have plenty of power-domains that do performance scaling > > too - and they stick with the power-domain binding, as it's > > sufficient. > > IMO, power-domains should be for power islands which can be power > gated. I know they are abused though. Of course, when things are > hidden in firmware, you don't really know. A power-domain could be > just a clock or a clock could be multiple physical clocks. I would also like to point out that it's perfectly possible that a power-domain can be a combination of a "power-island" and a performance-domain. In fact we have those cases already (Qcom, Tegra). > > > That said, I would rather follow the defacto standard that has been > > used for many years in the kernel. Do you have a preference that we > > should stick to? > > If power-domains are sufficient, then why do we have > performance-domains? We need clear rules for when to use what. Well, I think we invented the performance-domains bindings, especially with CPUs in mind. So far, that's the only use-case too (Mediatek, Apple). Even if I think the power-domains bindings would have worked fine for these cases too, maybe we should limit the performance-domains binding to be used for CPUs? Anyway, for the more generic use-case, I think the power-domains DT binding is better to stick with (it's what we have used for many years by now), as it provides us with the flexibility of hooking up an opp-table to the power-domain, allowing us to make the domain "performance-capable" too. Kind regards Uffe
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 5824c43e9893..cff9d1e4cea1 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -145,8 +145,8 @@ properties: '#clock-cells': const: 1 - required: - - '#clock-cells' + '#power-domain-cells': + const: 1 protocol@14: $ref: '#/$defs/protocol-node'