| Message ID | 20221024043925.25379-3-marcan@marcan.st (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Apple SoC cpufreq driver | expand |
On 24/10/2022 00:39, Hector Martin wrote: > This binding represents the cpufreq/DVFS hardware present in Apple SoCs. > The hardware has an independent controller per CPU cluster, and we > represent them as unique nodes in order to accurately describe the > hardware. The driver is responsible for binding them as a single cpufreq > device (in the Linux cpufreq model). > > Signed-off-by: Hector Martin <marcan@marcan.st> > --- > .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ > 1 file changed, 119 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > > diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > new file mode 100644 > index 000000000000..b11452f91468 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > @@ -0,0 +1,119 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple SoC cluster cpufreq device Few nits, in general looks fine to me. > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +description: | > + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of > + the cluster management register block. This binding uses the standard > + operating-points-v2 table to define the CPU performance states, with the > + opp-level property specifying the hardware p-state index for that level. > + > +properties: > + compatible: > + oneOf: > + - items: > + - const: apple,t8103-cluster-cpufreq > + - const: apple,cluster-cpufreq > + - items: > + - const: apple,t6000-cluster-cpufreq > + - const: apple,t8103-cluster-cpufreq > + - const: apple,cluster-cpufreq > + - items: > + - const: apple,t8112-cluster-cpufreq With the first one (t8103) - it's an enum. > + - const: apple,cluster-cpufreq > + > + reg: > + maxItems: 1 > + description: The register region for this CPU cluster DVFS controller Drop description, quite obvious. > + > + '#performance-domain-cells': > + const: 0 > + > +required: > + - compatible > + - reg > + - '#performance-domain-cells' > + > +additionalProperties: false > + > +examples: > + - | > + // This example shows a single CPU per domain and 2 domains, > + // with two p-states per domain. > + // Shipping hardware has 2-4 CPUs per domain and 2-6 domains. > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu@0 { > + compatible = "apple,icestorm"; > + device_type = "cpu"; > + reg = <0x0 0x0>; > + operating-points-v2 = <&ecluster_opp>; > + performance-domains = <&cpufreq_e>; > + }; > + > + cpu@10100 { > + compatible = "apple,firestorm"; > + device_type = "cpu"; > + reg = <0x0 0x10100>; > + operating-points-v2 = <&pcluster_opp>; > + performance-domains = <&cpufreq_p>; > + }; > + }; > + > + ecluster_opp: opp-table-0 { > + compatible = "operating-points-v2"; > + opp-shared; > + > + opp01 { > + opp-hz = /bits/ 64 <600000000>; > + opp-level = <1>; > + clock-latency-ns = <7500>; > + }; > + opp02 { > + opp-hz = /bits/ 64 <972000000>; > + opp-level = <2>; > + clock-latency-ns = <22000>; > + }; > + }; > + > + pcluster_opp: opp-table-1 { > + compatible = "operating-points-v2"; > + opp-shared; > + > + opp01 { > + opp-hz = /bits/ 64 <600000000>; > + opp-level = <1>; > + clock-latency-ns = <8000>; > + }; > + opp02 { > + opp-hz = /bits/ 64 <828000000>; > + opp-level = <2>; > + clock-latency-ns = <19000>; > + }; > + }; > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpufreq_e: cpufreq@210e20000 { Node name: performance-controller (cpufreq is rather Linux naming) > + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; > + reg = <0x2 0x10e20000 0 0x1000>; > + #performance-domain-cells = <0>; > + }; > + > + cpufreq_p: cpufreq@211e20000 { The same. > + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; > + reg = <0x2 0x11e20000 0 0x1000>; > + #performance-domain-cells = <0>; > + }; > + }; Best regards, Krzysztof
On 26/10/2022 01.01, Krzysztof Kozlowski wrote: > On 24/10/2022 00:39, Hector Martin wrote: >> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. >> The hardware has an independent controller per CPU cluster, and we >> represent them as unique nodes in order to accurately describe the >> hardware. The driver is responsible for binding them as a single cpufreq >> device (in the Linux cpufreq model). >> >> Signed-off-by: Hector Martin <marcan@marcan.st> >> --- >> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ >> 1 file changed, 119 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >> new file mode 100644 >> index 000000000000..b11452f91468 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >> @@ -0,0 +1,119 @@ >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Apple SoC cluster cpufreq device > > Few nits, in general looks fine to me. > >> + >> +maintainers: >> + - Hector Martin <marcan@marcan.st> >> + >> +description: | >> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of >> + the cluster management register block. This binding uses the standard >> + operating-points-v2 table to define the CPU performance states, with the >> + opp-level property specifying the hardware p-state index for that level. >> + >> +properties: >> + compatible: >> + oneOf: >> + - items: >> + - const: apple,t8103-cluster-cpufreq >> + - const: apple,cluster-cpufreq >> + - items: >> + - const: apple,t6000-cluster-cpufreq >> + - const: apple,t8103-cluster-cpufreq >> + - const: apple,cluster-cpufreq >> + - items: >> + - const: apple,t8112-cluster-cpufreq > > With the first one (t8103) - it's an enum. This is deliberate. t6000 is compatible with t8103, but t8112 is not (though all are compatible with what the generic apple,cluster-cpufreq compatible implies). Ack on the rest, I'll spin a v4 in a few days if there are no other comments. Thanks! - Hector
On 25/10/2022 13:22, Hector Martin wrote: > On 26/10/2022 01.01, Krzysztof Kozlowski wrote: >> On 24/10/2022 00:39, Hector Martin wrote: >>> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. >>> The hardware has an independent controller per CPU cluster, and we >>> represent them as unique nodes in order to accurately describe the >>> hardware. The driver is responsible for binding them as a single cpufreq >>> device (in the Linux cpufreq model). >>> >>> Signed-off-by: Hector Martin <marcan@marcan.st> >>> --- >>> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ >>> 1 file changed, 119 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>> new file mode 100644 >>> index 000000000000..b11452f91468 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>> @@ -0,0 +1,119 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Apple SoC cluster cpufreq device >> >> Few nits, in general looks fine to me. >> >>> + >>> +maintainers: >>> + - Hector Martin <marcan@marcan.st> >>> + >>> +description: | >>> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of >>> + the cluster management register block. This binding uses the standard >>> + operating-points-v2 table to define the CPU performance states, with the >>> + opp-level property specifying the hardware p-state index for that level. >>> + >>> +properties: >>> + compatible: >>> + oneOf: >>> + - items: >>> + - const: apple,t8103-cluster-cpufreq >>> + - const: apple,cluster-cpufreq >>> + - items: >>> + - const: apple,t6000-cluster-cpufreq >>> + - const: apple,t8103-cluster-cpufreq >>> + - const: apple,cluster-cpufreq >>> + - items: >>> + - const: apple,t8112-cluster-cpufreq >> >> With the first one (t8103) - it's an enum. > > This is deliberate. t6000 is compatible with t8103, but t8112 is not > (though all are compatible with what the generic apple,cluster-cpufreq > compatible implies). I was not talking about t6000. I was talking about two entries - first and last - which should be just an enum. There is no compatibility, so what is here deliberate? To not make enum things which are an enum? Best regards, Krzysztof
On Wed, Oct 26, 2022 at 02:22:40AM +0900, Hector Martin wrote: > On 26/10/2022 01.01, Krzysztof Kozlowski wrote: > > On 24/10/2022 00:39, Hector Martin wrote: > >> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. > >> The hardware has an independent controller per CPU cluster, and we > >> represent them as unique nodes in order to accurately describe the > >> hardware. The driver is responsible for binding them as a single cpufreq > >> device (in the Linux cpufreq model). > >> > >> Signed-off-by: Hector Martin <marcan@marcan.st> > >> --- > >> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ > >> 1 file changed, 119 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> > >> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> new file mode 100644 > >> index 000000000000..b11452f91468 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> @@ -0,0 +1,119 @@ > >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Apple SoC cluster cpufreq device > > > > Few nits, in general looks fine to me. > > > >> + > >> +maintainers: > >> + - Hector Martin <marcan@marcan.st> > >> + > >> +description: | > >> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of > >> + the cluster management register block. This binding uses the standard > >> + operating-points-v2 table to define the CPU performance states, with the > >> + opp-level property specifying the hardware p-state index for that level. > >> + > >> +properties: > >> + compatible: > >> + oneOf: > >> + - items: > >> + - const: apple,t8103-cluster-cpufreq > >> + - const: apple,cluster-cpufreq > >> + - items: > >> + - const: apple,t6000-cluster-cpufreq > >> + - const: apple,t8103-cluster-cpufreq > >> + - const: apple,cluster-cpufreq > >> + - items: > >> + - const: apple,t8112-cluster-cpufreq > > > > With the first one (t8103) - it's an enum. > > This is deliberate. t6000 is compatible with t8103, but t8112 is not > (though all are compatible with what the generic apple,cluster-cpufreq > compatible implies). What does compatible mean here? IOW, what can a client do with 'apple,cluster-cpufreq' alone? It's one thing for self-contained blocks to remain unchanged from chip to chip, but things like this tend to change frequently. It looks like for 4 chips we have 3 different versions. Rob
On 26/10/2022 03.56, Krzysztof Kozlowski wrote: > On 25/10/2022 13:22, Hector Martin wrote: >> On 26/10/2022 01.01, Krzysztof Kozlowski wrote: >>> On 24/10/2022 00:39, Hector Martin wrote: >>>> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. >>>> The hardware has an independent controller per CPU cluster, and we >>>> represent them as unique nodes in order to accurately describe the >>>> hardware. The driver is responsible for binding them as a single cpufreq >>>> device (in the Linux cpufreq model). >>>> >>>> Signed-off-by: Hector Martin <marcan@marcan.st> >>>> --- >>>> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ >>>> 1 file changed, 119 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> new file mode 100644 >>>> index 000000000000..b11452f91468 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> @@ -0,0 +1,119 @@ >>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Apple SoC cluster cpufreq device >>> >>> Few nits, in general looks fine to me. >>> >>>> + >>>> +maintainers: >>>> + - Hector Martin <marcan@marcan.st> >>>> + >>>> +description: | >>>> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of >>>> + the cluster management register block. This binding uses the standard >>>> + operating-points-v2 table to define the CPU performance states, with the >>>> + opp-level property specifying the hardware p-state index for that level. >>>> + >>>> +properties: >>>> + compatible: >>>> + oneOf: >>>> + - items: >>>> + - const: apple,t8103-cluster-cpufreq >>>> + - const: apple,cluster-cpufreq >>>> + - items: >>>> + - const: apple,t6000-cluster-cpufreq >>>> + - const: apple,t8103-cluster-cpufreq >>>> + - const: apple,cluster-cpufreq >>>> + - items: >>>> + - const: apple,t8112-cluster-cpufreq >>> >>> With the first one (t8103) - it's an enum. >> >> This is deliberate. t6000 is compatible with t8103, but t8112 is not >> (though all are compatible with what the generic apple,cluster-cpufreq >> compatible implies). > > I was not talking about t6000. I was talking about two entries - first > and last - which should be just an enum. There is no compatibility, so > what is here deliberate? To not make enum things which are an enum? Sorry, I didn't understand what you meant. You mean that the two entries should be merged, with an enum for the first item listing both SoCs, right? - Hector
On 26/10/2022 08.12, Rob Herring wrote: > On Wed, Oct 26, 2022 at 02:22:40AM +0900, Hector Martin wrote: >> On 26/10/2022 01.01, Krzysztof Kozlowski wrote: >>> On 24/10/2022 00:39, Hector Martin wrote: >>>> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. >>>> The hardware has an independent controller per CPU cluster, and we >>>> represent them as unique nodes in order to accurately describe the >>>> hardware. The driver is responsible for binding them as a single cpufreq >>>> device (in the Linux cpufreq model). >>>> >>>> Signed-off-by: Hector Martin <marcan@marcan.st> >>>> --- >>>> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ >>>> 1 file changed, 119 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> new file mode 100644 >>>> index 000000000000..b11452f91468 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml >>>> @@ -0,0 +1,119 @@ >>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Apple SoC cluster cpufreq device >>> >>> Few nits, in general looks fine to me. >>> >>>> + >>>> +maintainers: >>>> + - Hector Martin <marcan@marcan.st> >>>> + >>>> +description: | >>>> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of >>>> + the cluster management register block. This binding uses the standard >>>> + operating-points-v2 table to define the CPU performance states, with the >>>> + opp-level property specifying the hardware p-state index for that level. >>>> + >>>> +properties: >>>> + compatible: >>>> + oneOf: >>>> + - items: >>>> + - const: apple,t8103-cluster-cpufreq >>>> + - const: apple,cluster-cpufreq >>>> + - items: >>>> + - const: apple,t6000-cluster-cpufreq >>>> + - const: apple,t8103-cluster-cpufreq >>>> + - const: apple,cluster-cpufreq >>>> + - items: >>>> + - const: apple,t8112-cluster-cpufreq >>> >>> With the first one (t8103) - it's an enum. >> >> This is deliberate. t6000 is compatible with t8103, but t8112 is not >> (though all are compatible with what the generic apple,cluster-cpufreq >> compatible implies). > > What does compatible mean here? IOW, what can a client do with > 'apple,cluster-cpufreq' alone? It's one thing for self-contained blocks > to remain unchanged from chip to chip, but things like this tend to > change frequently. It looks like for 4 chips we have 3 different > versions. This is described in the cover letter. The actual cpufreq control is identical for all shipping SoCs right now (that's 5 SoCs, since t6000 is actually also t6001 and t6002) and will work with just that generic compatible (and almost certainly quite a few SoC generations going back too). It's just that I found a useful register that gives you feedback on the *actual* pstate, and that register field shifted one bit on t8112 because they ran out of bits. If the driver finds a t8103 or t8112 compatible, it will use that register to accurately report the current frequency (subject to boost frequency restrictions). If it doesn't, it will just report the requested frequency as actual. t6000 is compatible with t8103 in this regard, hence the tiering. I expect lots of future SoCs to be compatible with t8112, since although they exceeded 16 pstates there, I doubt they'll push beyond 32 and have to move it another bit any time soon. Right *now*, since boost frequencies are unachievable and disabled due to reasons unrelated to this driver, all compatibles are, in fact, completely equivalent in functionality for end users, and nothing would change if we just had `apple,cluster-cpufreq` in the DT. This will change once we get cpuidle support, which unlocks boost frequencies as a side effect, but that will require no changes to this driver/series (other than uncommenting the extra OPPs in the DT). - Hector
On 26/10/2022 00:18, Hector Martin wrote: >>>> With the first one (t8103) - it's an enum. >>> >>> This is deliberate. t6000 is compatible with t8103, but t8112 is not >>> (though all are compatible with what the generic apple,cluster-cpufreq >>> compatible implies). >> >> I was not talking about t6000. I was talking about two entries - first >> and last - which should be just an enum. There is no compatibility, so >> what is here deliberate? To not make enum things which are an enum? > > Sorry, I didn't understand what you meant. You mean that the two entries > should be merged, with an enum for the first item listing both SoCs, right? Yes Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml new file mode 100644 index 000000000000..b11452f91468 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoC cluster cpufreq device + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: | + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of + the cluster management register block. This binding uses the standard + operating-points-v2 table to define the CPU performance states, with the + opp-level property specifying the hardware p-state index for that level. + +properties: + compatible: + oneOf: + - items: + - const: apple,t8103-cluster-cpufreq + - const: apple,cluster-cpufreq + - items: + - const: apple,t6000-cluster-cpufreq + - const: apple,t8103-cluster-cpufreq + - const: apple,cluster-cpufreq + - items: + - const: apple,t8112-cluster-cpufreq + - const: apple,cluster-cpufreq + + reg: + maxItems: 1 + description: The register region for this CPU cluster DVFS controller + + '#performance-domain-cells': + const: 0 + +required: + - compatible + - reg + - '#performance-domain-cells' + +additionalProperties: false + +examples: + - | + // This example shows a single CPU per domain and 2 domains, + // with two p-states per domain. + // Shipping hardware has 2-4 CPUs per domain and 2-6 domains. + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu@0 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x0>; + operating-points-v2 = <&ecluster_opp>; + performance-domains = <&cpufreq_e>; + }; + + cpu@10100 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10100>; + operating-points-v2 = <&pcluster_opp>; + performance-domains = <&cpufreq_p>; + }; + }; + + ecluster_opp: opp-table-0 { + compatible = "operating-points-v2"; + opp-shared; + + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-level = <1>; + clock-latency-ns = <7500>; + }; + opp02 { + opp-hz = /bits/ 64 <972000000>; + opp-level = <2>; + clock-latency-ns = <22000>; + }; + }; + + pcluster_opp: opp-table-1 { + compatible = "operating-points-v2"; + opp-shared; + + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-level = <1>; + clock-latency-ns = <8000>; + }; + opp02 { + opp-hz = /bits/ 64 <828000000>; + opp-level = <2>; + clock-latency-ns = <19000>; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + cpufreq_e: cpufreq@210e20000 { + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; + reg = <0x2 0x10e20000 0 0x1000>; + #performance-domain-cells = <0>; + }; + + cpufreq_p: cpufreq@211e20000 { + compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq"; + reg = <0x2 0x11e20000 0 0x1000>; + #performance-domain-cells = <0>; + }; + };
This binding represents the cpufreq/DVFS hardware present in Apple SoCs. The hardware has an independent controller per CPU cluster, and we represent them as unique nodes in order to accurately describe the hardware. The driver is responsible for binding them as a single cpufreq device (in the Linux cpufreq model). Signed-off-by: Hector Martin <marcan@marcan.st> --- .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml