On Thu, 15 Jun 2023 at 10:44, Sudeep Holla <sudeep.holla@xxxxxxx> 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@xxxxxxxxxx> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx> > > Cc: Conor Dooley <conor+dt@xxxxxxxxxx> > > Cc: devicetree@xxxxxxxxxxxxxxx > > Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > > --- > > 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
