On Fri, 14 Jul 2023 at 19:15, Rob Herring <robh@xxxxxxxxxx> wrote: > > 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. I would also like to point out that it's perfectly possible that a power-domain can be a combination of a "power-island" and a performance-domain. In fact we have those cases already (Qcom, Tegra). > > > 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. Well, I think we invented the performance-domains bindings, especially with CPUs in mind. So far, that's the only use-case too (Mediatek, Apple). Even if I think the power-domains bindings would have worked fine for these cases too, maybe we should limit the performance-domains binding to be used for CPUs? Anyway, for the more generic use-case, I think the power-domains DT binding is better to stick with (it's what we have used for many years by now), as it provides us with the flexibility of hooking up an opp-table to the power-domain, allowing us to make the domain "performance-capable" too. Kind regards Uffe
