| Message ID | 20240403111106.1110940-1-ulf.hansson@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dt-bindings: firmware: arm,scmi: Update examples for protocol@13 | expand |
On Wed, Apr 03, 2024 at 01:11:06PM +0200, Ulf Hansson wrote: > Recently we extended the binding for protocol@13 to allow it to be modelled > as a generic performance domain. In a way to promote using the new binding, > let's update the examples. > Does it make sense to keep one DVFS example with #clock-cells until we mark it as deprecated ? Otherwise it may be confusing as the binding still lists. Or leave some comment in the example or something, I am open for suggestions. Other than that, Acked-by: Sudeep Holla <sudeep.holla@arm.com>
On Wed, 3 Apr 2024 at 15:53, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Wed, Apr 03, 2024 at 01:11:06PM +0200, Ulf Hansson wrote: > > Recently we extended the binding for protocol@13 to allow it to be modelled > > as a generic performance domain. In a way to promote using the new binding, > > let's update the examples. > > > > Does it make sense to keep one DVFS example with #clock-cells until we > mark it as deprecated ? Otherwise it may be confusing as the binding still > lists. Or leave some comment in the example or something, I am open for > suggestions. I am certainly fine with either way! However, if we intend to make #clock-cells deprecated down the road, maybe it's better to start avoiding the use of it already now. That said, what do you think of following up $subject patch with an update to Juno's dts(i) to move to #power-domains-cells too? That would mean we get a nice reference for how to use this too. > > Other than that, > > Acked-by: Sudeep Holla <sudeep.holla@arm.com> Are you picking this via your scmi tree, or which route is this going? > > -- > Regards, > Sudeep Kind regards Uffe
On Thu, Apr 04, 2024 at 12:52:08PM +0200, Ulf Hansson wrote: > On Wed, 3 Apr 2024 at 15:53, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > On Wed, Apr 03, 2024 at 01:11:06PM +0200, Ulf Hansson wrote: > > > Recently we extended the binding for protocol@13 to allow it to be modelled > > > as a generic performance domain. In a way to promote using the new binding, > > > let's update the examples. > > > > > > > Does it make sense to keep one DVFS example with #clock-cells until we > > mark it as deprecated ? Otherwise it may be confusing as the binding still > > lists. Or leave some comment in the example or something, I am open for > > suggestions. > > I am certainly fine with either way! > > However, if we intend to make #clock-cells deprecated down the road, > maybe it's better to start avoiding the use of it already now. That > said, what do you think of following up $subject patch with an update > to Juno's dts(i) to move to #power-domains-cells too? That would mean > we get a nice reference for how to use this too. > > > > > Other than that, > > > > Acked-by: Sudeep Holla <sudeep.holla@arm.com> > > Are you picking this via your scmi tree, or which route is this going? Please take via SCMI tree. Acked-by: Rob Herring <robh@kernel.org>
On Wed, Apr 10, 2024 at 06:56:37AM -0500, Rob Herring wrote: > On Thu, Apr 04, 2024 at 12:52:08PM +0200, Ulf Hansson wrote: > > On Wed, 3 Apr 2024 at 15:53, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On Wed, Apr 03, 2024 at 01:11:06PM +0200, Ulf Hansson wrote: > > > > Recently we extended the binding for protocol@13 to allow it to be modelled > > > > as a generic performance domain. In a way to promote using the new binding, > > > > let's update the examples. > > > > > > > > > > Does it make sense to keep one DVFS example with #clock-cells until we > > > mark it as deprecated ? Otherwise it may be confusing as the binding still > > > lists. Or leave some comment in the example or something, I am open for > > > suggestions. > > > > I am certainly fine with either way! > > > > However, if we intend to make #clock-cells deprecated down the road, > > maybe it's better to start avoiding the use of it already now. That > > said, what do you think of following up $subject patch with an update > > to Juno's dts(i) to move to #power-domains-cells too? That would mean > > we get a nice reference for how to use this too. > > > > > > > > Other than that, > > > > > > Acked-by: Sudeep Holla <sudeep.holla@arm.com> > > > > Are you picking this via your scmi tree, or which route is this going? > Sorry Ulf, this slipped through the cracks, will queue it. > Please take via SCMI tree. > Sure > Acked-by: Rob Herring <robh@kernel.org> Thanks
On Wed, 03 Apr 2024 13:11:06 +0200, Ulf Hansson wrote: > Recently we extended the binding for protocol@13 to allow it to be modelled > as a generic performance domain. In a way to promote using the new binding, > let's update the examples. > Applied to sudeep.holla/linux (for-next/scmi/updates), thanks! [1/1] dt-bindings: firmware: arm,scmi: Update examples for protocol@13 https://git.kernel.org/sudeep.holla/c/4625810361d6 -- Regards, Sudeep
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 4591523b51a0..93fb7d05f849 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -355,7 +355,7 @@ examples: scmi_dvfs: protocol@13 { reg = <0x13>; - #clock-cells = <1>; + #power-domain-cells = <1>; mboxes = <&mhuB 1 0>, <&mhuB 1 1>; @@ -468,7 +468,7 @@ examples: reg = <0x13>; linaro,optee-channel-id = <1>; shmem = <&cpu_optee_lpri0>; - #clock-cells = <1>; + #power-domain-cells = <1>; }; scmi_clk0: protocol@14 {
Recently we extended the binding for protocol@13 to allow it to be modelled as a generic performance domain. In a way to promote using the new binding, let's update the examples. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> --- Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)