Message ID | 20230713141738.23970-9-ulf.hansson@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1862057vqm; Thu, 13 Jul 2023 07:25:37 -0700 (PDT) X-Google-Smtp-Source: APBJJlFHqaNKlaAUTM9wwNO5P+waXY1LvVERv6/+3cPmouBmyQ+th5bPaRRu8hHI3N/jWZxGhShT X-Received: by 2002:a17:906:2253:b0:993:e860:f20 with SMTP id 19-20020a170906225300b00993e8600f20mr1921817ejr.19.1689258337099; Thu, 13 Jul 2023 07:25:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689258337; cv=none; d=google.com; s=arc-20160816; b=0PqTDFsyKeai83ypmOTBma35vFMA9Sl3pijbQpPcLXtO1JXQq7ZXXcsxt1bS9X3FGa RhyQHq4vSMePNkYQYBLsnQnlHAKbe9IdlmUaOVND7yaz8FfRhOUxhce7XO5vhw3Y5rwL yvhD9wKTIqdAy1x+0jE4R6uY6XrRHGqJZB2gvzZiPVIf7qNpAZN4r8eBVbPFmrAKYSMt MalziqRsTU/COIOBb4nX1L7qvdj/fGWQkksCKIixbu5yWHYP169sPYraKIdpunDielmS SJApjYS+cfR857K+cc4V0O5jrW0Wkozf8ioneZC1yS3BpX6WaBmCiZ2y0tDg2qUO82BZ GNhg== 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=B9RUZ+b+emtSv+giCmXNPmhFjp4/hvFKRq4dSR9PST4=; fh=Zo4Thru3tZ0letwsQK6+k94pGJizT4N48rRjHTYNkBw=; b=odnikRp2S5bDWtqUhMrmjq5liYLtK74J/VQy/Uh+yrO2qT8i0dcjaCCQM90ArlYcZY 4u1stsWsS4ZIjjYr5f2xNPvvsa0j8C1XgenqvJFzUFXs114Gao9eROc6uJVqkdvcAu0M hA5d/3gYmo70gQDSJEp/+dyv/ybphoKEkOQJM6MAWG+6pZIi274Oyot0c8iSMJT79kR4 DLaJGlvaf2E0ttOIFmXHyZqBmJeAj1SJdVBH2NdlmWKFSHMXOwJRTirPZZzVnHZNwgmg wsBS4N1e4bs0637gd6z/1s1SNzvjt/tf6ChNAOM+zJXJENY93isUWJ4gYzjnxlHrqPfk PJlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=r86Mnb2s; 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 g25-20020a1709064e5900b00988939ad0bdsi7586572ejw.321.2023.07.13.07.24.55; Thu, 13 Jul 2023 07:25:37 -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=r86Mnb2s; 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 S229719AbjGMOTT (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 13 Jul 2023 10:19:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229819AbjGMOSY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Jul 2023 10:18:24 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE8AE2713 for <linux-kernel@vger.kernel.org>; Thu, 13 Jul 2023 07:18:21 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4fb761efa7aso1341052e87.0 for <linux-kernel@vger.kernel.org>; Thu, 13 Jul 2023 07:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689257900; x=1691849900; 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=B9RUZ+b+emtSv+giCmXNPmhFjp4/hvFKRq4dSR9PST4=; b=r86Mnb2sxhN41eDyo1Lz3DzPrPX5ROyFP2J8LlwjDP1AtlgU+TxSvGJvGeLL3wkoWe Cb/9weYQqYWEfbFh/CGQ0qj1uMrbTjRVm48CrwWAgz6Y1MMTsKH4gmUGrNeNyPmgnzoz I/lRNDtExpc8KFid2vfy61dek6hP6EL7lhcqHIg+6fNcbv8IyVCACsNT+TLUf24d1Wcd HxukzMnGtuRHc6Ed/GxXF3lVfclBTHVjen4UXtsoLBJcsF5ECT0Ib/252D7fRnXTQPsj bBZYHJvq76LatXZ4tmyrPlz9q2T5vpHcPMqavsHn6wsyfsqtqguhWOzDdUpPOw7yRDwr qWvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689257900; x=1691849900; 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=B9RUZ+b+emtSv+giCmXNPmhFjp4/hvFKRq4dSR9PST4=; b=MIGUFMGaqBDDoYKBwCbYnHE30M6wQGr0iIjZWHE46T01CNygp7MYzKzfGVd9S2eU7q BRoqApnEacoDGNyNhWPbpRQI4SeifxGHoRhXFmMolA2AMGh5G7GIBXDc13HHSVGbtwR7 mkXsUVrjy+IPNAw4/ZQSHCUkZijEsxVI0ym+kvOaBaPVC+NUMEybtnbWS6P72e+pwCq9 umW8TaI2uOjfW3MPk94uPTGv8lat8iJUPWKSIKLRl79iUHN2MtGwecRHngwfXuy6nTUu TsUISETDmbZdvfmtkHvYX7HhpHZ+YGL9Y/F9DdJfeXJvtZOHz2wIsz0HRvxQ8TvxEJ6C 1t2w== X-Gm-Message-State: ABy/qLYub/shnwXEmM0ljiqC+fSpgPkSxOo76FocZpi4Nws0h4pg65yq wtt+262MF36w0NuXiFkFJWlPkQ== X-Received: by 2002:a05:6512:31d3:b0:4f8:6d54:72fa with SMTP id j19-20020a05651231d300b004f86d5472famr1770618lfe.2.1689257900089; Thu, 13 Jul 2023 07:18:20 -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 w28-20020ac2599c000000b004fb759964a9sm1132426lfn.168.2023.07.13.07.18.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jul 2023 07:18:19 -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 v2 08/11] dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13 Date: Thu, 13 Jul 2023 16:17:35 +0200 Message-Id: <20230713141738.23970-9-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230713141738.23970-1-ulf.hansson@linaro.org> References: <20230713141738.23970-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_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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: INBOX X-GMAIL-THRID: 1771315749986746995 X-GMAIL-MSGID: 1771315749986746995 |
Series |
arm_scmi/cpufreq: Add generic performance scaling support
|
|
Commit Message
Ulf Hansson
July 13, 2023, 2:17 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 domaintoo. The common way to describe this, is to use
the "power-domain" DT 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>
---
Changes in v2:
- Updated the DT binding to require "oneOf" #power-domain-cells or
#clock-cells.
---
.../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
Comments
On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > the "power-domain" DT bindings, so let's use that. > One thing I forgot to ask earlier is how we can manage different domain IDs for perf and power domains which is the case with current SCMI platforms as the spec never mandated or can ever mandate the perf and power domains IDs to match. They need not be same anyways. -- Regards, Sudeep
On Wed, 19 Jul 2023 at 17:17, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > > the "power-domain" DT bindings, so let's use that. > > > > One thing I forgot to ask earlier is how we can manage different domain IDs > for perf and power domains which is the case with current SCMI platforms as > the spec never mandated or can ever mandate the perf and power domains IDs > to match. They need not be same anyways. Based upon what you describe above, I have modelled the perf-domain and the power-domain as two separate power-domain providers. A consumer device being hooked up to both domains, would specify the domain IDs in the second power-domain-cell, along the lines of the below. Then we would use power-domain-names to specify what each power-domain represents. power-domains = <&scmi_pd 2>, <&scmi_dvfs 4>; power-domain-names = "power", "perf"; I hope this makes it clearer!? Kind regards Uffe
On Fri, Jul 21, 2023 at 01:42:43PM +0200, Ulf Hansson wrote: > On Wed, 19 Jul 2023 at 17:17, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > > > the "power-domain" DT bindings, so let's use that. > > > > > > > One thing I forgot to ask earlier is how we can manage different domain IDs > > for perf and power domains which is the case with current SCMI platforms as > > the spec never mandated or can ever mandate the perf and power domains IDs > > to match. They need not be same anyways. > > Based upon what you describe above, I have modelled the perf-domain > and the power-domain as two separate power-domain providers. > > A consumer device being hooked up to both domains, would specify the > domain IDs in the second power-domain-cell, along the lines of the > below. Then we would use power-domain-names to specify what each > power-domain represents. > > power-domains = <&scmi_pd 2>, <&scmi_dvfs 4>; > power-domain-names = "power", "perf"; > > I hope this makes it clearer!? Yes it make is clear definitely, but it does change the definition of the generic binding of the "power-domains" property now. I am interesting in the feedback from the binding maintainers with respect to that. Or is it already present ? IIUC, the ones supported already are generally both power and performance providers. May be it doesn't matter much, just wanted to explicit ask and confirm those details. -- Regards, Sudeep
On Fri, Jul 21, 2023 at 12:55:35PM +0100, Sudeep Holla wrote: > On Fri, Jul 21, 2023 at 01:42:43PM +0200, Ulf Hansson wrote: > > On Wed, 19 Jul 2023 at 17:17, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > > > > the "power-domain" DT bindings, so let's use that. > > > > > > > > > > One thing I forgot to ask earlier is how we can manage different domain IDs > > > for perf and power domains which is the case with current SCMI platforms as > > > the spec never mandated or can ever mandate the perf and power domains IDs > > > to match. They need not be same anyways. > > > > Based upon what you describe above, I have modelled the perf-domain > > and the power-domain as two separate power-domain providers. > > > > A consumer device being hooked up to both domains, would specify the > > domain IDs in the second power-domain-cell, along the lines of the > > below. Then we would use power-domain-names to specify what each > > power-domain represents. > > > > power-domains = <&scmi_pd 2>, <&scmi_dvfs 4>; > > power-domain-names = "power", "perf"; > > > > I hope this makes it clearer!? > > Yes it make is clear definitely, but it does change the definition of the > generic binding of the "power-domains" property now. I am interesting in > the feedback from the binding maintainers with respect to that. Or is it > already present ? IIUC, the ones supported already are generally both > power and performance providers. May be it doesn't matter much, just > wanted to explicit ask and confirm those details. I commented on v1. Looks like abuse of "power-domains" to me, but nothing new really. Please define when to use a power domain vs. a perf domain and don't leave it up to the whims of the platform. Maybe perf domains was a mistake and they should be deprecated? Rob
On Fri, Jul 21, 2023 at 08:33:04AM -0600, Rob Herring wrote: > On Fri, Jul 21, 2023 at 12:55:35PM +0100, Sudeep Holla wrote: > > On Fri, Jul 21, 2023 at 01:42:43PM +0200, Ulf Hansson wrote: > > > On Wed, 19 Jul 2023 at 17:17, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > > > On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > > > > > the "power-domain" DT bindings, so let's use that. > > > > > > > > > > > > > One thing I forgot to ask earlier is how we can manage different domain IDs > > > > for perf and power domains which is the case with current SCMI platforms as > > > > the spec never mandated or can ever mandate the perf and power domains IDs > > > > to match. They need not be same anyways. > > > > > > Based upon what you describe above, I have modelled the perf-domain > > > and the power-domain as two separate power-domain providers. > > > > > > A consumer device being hooked up to both domains, would specify the > > > domain IDs in the second power-domain-cell, along the lines of the > > > below. Then we would use power-domain-names to specify what each > > > power-domain represents. > > > > > > power-domains = <&scmi_pd 2>, <&scmi_dvfs 4>; > > > power-domain-names = "power", "perf"; > > > > > > I hope this makes it clearer!? > > > > Yes it make is clear definitely, but it does change the definition of the > > generic binding of the "power-domains" property now. I am interesting in > > the feedback from the binding maintainers with respect to that. Or is it > > already present ? IIUC, the ones supported already are generally both > > power and performance providers. May be it doesn't matter much, just > > wanted to explicit ask and confirm those details. > > I commented on v1. > > Looks like abuse of "power-domains" to me, but nothing new really. > Please define when to use a power domain vs. a perf domain and don't > leave it up to the whims of the platform. Maybe perf domains was a > mistake and they should be deprecated? > Just a thought here, instead of deprecating it I was thinking if possible to keep the power-domains and performance-domains separate and just extend the genpd to handle the latter. There by we are not mixing up and creating confusions that need more specific definitions in the binding(which is not a big deal) but platforms getting it wrong inspite of that is a big problem. Keep it separate makes it more aligned to the hardware and doesn't dilute the definitions and probably avoids any possible mistakes due to that. Sorry Ulf I am just not yet convinced to mix them up yet 😉 and wish you don't convince me to. Let me know why the above suggestion won't work.
On Fri, 21 Jul 2023 at 20:38, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Fri, Jul 21, 2023 at 08:33:04AM -0600, Rob Herring wrote: > > On Fri, Jul 21, 2023 at 12:55:35PM +0100, Sudeep Holla wrote: > > > On Fri, Jul 21, 2023 at 01:42:43PM +0200, Ulf Hansson wrote: > > > > On Wed, 19 Jul 2023 at 17:17, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > > > > > On Thu, Jul 13, 2023 at 04:17:35PM +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 domaintoo. The common way to describe this, is to use > > > > > > the "power-domain" DT bindings, so let's use that. > > > > > > > > > > > > > > > > One thing I forgot to ask earlier is how we can manage different domain IDs > > > > > for perf and power domains which is the case with current SCMI platforms as > > > > > the spec never mandated or can ever mandate the perf and power domains IDs > > > > > to match. They need not be same anyways. > > > > > > > > Based upon what you describe above, I have modelled the perf-domain > > > > and the power-domain as two separate power-domain providers. > > > > > > > > A consumer device being hooked up to both domains, would specify the > > > > domain IDs in the second power-domain-cell, along the lines of the > > > > below. Then we would use power-domain-names to specify what each > > > > power-domain represents. > > > > > > > > power-domains = <&scmi_pd 2>, <&scmi_dvfs 4>; > > > > power-domain-names = "power", "perf"; > > > > > > > > I hope this makes it clearer!? > > > > > > Yes it make is clear definitely, but it does change the definition of the > > > generic binding of the "power-domains" property now. I am interesting in > > > the feedback from the binding maintainers with respect to that. Or is it > > > already present ? IIUC, the ones supported already are generally both > > > power and performance providers. May be it doesn't matter much, just > > > wanted to explicit ask and confirm those details. > > > > I commented on v1. > > > > Looks like abuse of "power-domains" to me, but nothing new really. > > Please define when to use a power domain vs. a perf domain and don't > > leave it up to the whims of the platform. Maybe perf domains was a > > mistake and they should be deprecated? > > > > Just a thought here, instead of deprecating it I was thinking if possible > to keep the power-domains and performance-domains separate and just extend > the genpd to handle the latter. There by we are not mixing up and creating > confusions that need more specific definitions in the binding(which is not > a big deal) but platforms getting it wrong inspite of that is a big problem. > Keep it separate makes it more aligned to the hardware and doesn't dilute > the definitions and probably avoids any possible mistakes due to that. > > Sorry Ulf I am just not yet convinced to mix them up yet 😉 and wish you > don't convince me to. Let me know why the above suggestion won't work. The main point I think we need to consider too, is that on some platforms, the power-domain and the performance-domain are managed together by the FW. It is not really two separate things and hence it would not quite be correct to describe it as two different types of providers in DT. If we should follow your suggestion above, to use the performance-domain bindings, then I think we need an additional new binding to cover the above mentioned case too. This would lead us into having one binding for the power-domain, another for the performance-domain and a third for the power+performance-domain. In my opinion this sounds quite like a mess. I would rather keep using the power-domain bindings for all these cases. Of course, it's a bit of a stretch too, but I think it should be less confusing in the end, assuming we extend/clarify the description of the power-domain bindings, of course. Did that convince you? :-) Kind regards Uffe
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index b138f3d23df8..563a87dfb31a 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -149,8 +149,15 @@ properties: '#clock-cells': const: 1 - required: - - '#clock-cells' + '#power-domain-cells': + const: 1 + + oneOf: + - required: + - '#clock-cells' + + - required: + - '#power-domain-cells' protocol@14: $ref: '#/$defs/protocol-node'