On Thu, Jun 15, 2023 at 3:11 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Thu, 15 Jun 2023 at 01:00, Rob Herring <robh@xxxxxxxxxx> 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
