| Message ID | 20230713141738.23970-9-ulf.hansson@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | viresh kumar |
| Headers | show |
| Series | arm_scmi/cpufreq: Add generic performance scaling support | expand |
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
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
On Wed, 26 Jul 2023 at 13:12, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > 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
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'
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(-)