From: Rob Herring <robh@kernel.org>
To: Hector Martin <marcan@marcan.st>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sven Peter <sven@svenpeter.dev>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Marc Zyngier <maz@kernel.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq
Date: Tue, 25 Oct 2022 18:12:36 -0500 [thread overview]
Message-ID: <20221025231236.GA3416036-robh@kernel.org> (raw)
In-Reply-To: <97d3d6d4-b19c-a194-de41-f17e65bf3eb6@marcan.st>
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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Hector Martin <marcan@marcan.st>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sven Peter <sven@svenpeter.dev>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Marc Zyngier <maz@kernel.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq
Date: Tue, 25 Oct 2022 18:12:36 -0500 [thread overview]
Message-ID: <20221025231236.GA3416036-robh@kernel.org> (raw)
In-Reply-To: <97d3d6d4-b19c-a194-de41-f17e65bf3eb6@marcan.st>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-25 23:12 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 4:39 [PATCH v3 0/5] Apple SoC cpufreq driver Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-10-24 4:39 ` [PATCH v3 1/5] MAINTAINERS: Add entries for " Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-10-24 4:39 ` [PATCH v3 2/5] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-10-25 16:01 ` Krzysztof Kozlowski
2022-10-25 16:01 ` Krzysztof Kozlowski
2022-10-25 17:22 ` Hector Martin
2022-10-25 17:22 ` Hector Martin
2022-10-25 18:56 ` Krzysztof Kozlowski
2022-10-25 18:56 ` Krzysztof Kozlowski
2022-10-26 4:18 ` Hector Martin
2022-10-26 4:18 ` Hector Martin
2022-10-26 14:13 ` Krzysztof Kozlowski
2022-10-26 14:13 ` Krzysztof Kozlowski
2022-10-25 23:12 ` Rob Herring [this message]
2022-10-25 23:12 ` Rob Herring
2022-10-26 4:26 ` Hector Martin
2022-10-26 4:26 ` Hector Martin
2022-10-24 4:39 ` [PATCH v3 3/5] cpufreq: Generalize of_perf_domain_get_sharing_cpumask phandle format Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-11-02 5:37 ` Viresh Kumar
2022-11-02 5:37 ` Viresh Kumar
2022-10-24 4:39 ` [PATCH v3 4/5] cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-10-24 8:27 ` Marc Zyngier
2022-10-24 8:27 ` Marc Zyngier
2022-11-09 12:13 ` Hector Martin
2022-11-09 12:13 ` Hector Martin
2022-11-09 14:20 ` Marc Zyngier
2022-11-09 14:20 ` Marc Zyngier
2022-11-09 15:39 ` Hector Martin
2022-11-09 15:39 ` Hector Martin
2022-11-01 15:16 ` Ulf Hansson
2022-11-01 15:16 ` Ulf Hansson
2022-11-01 18:17 ` Hector Martin
2022-11-01 18:17 ` Hector Martin
2022-11-14 19:49 ` Ulf Hansson
2022-11-14 19:49 ` Ulf Hansson
2022-11-02 6:18 ` Viresh Kumar
2022-11-02 6:18 ` Viresh Kumar
2022-11-09 12:36 ` Hector Martin
2022-11-09 12:36 ` Hector Martin
2022-11-14 6:51 ` Viresh Kumar
2022-11-14 6:51 ` Viresh Kumar
2022-11-14 6:57 ` Hector Martin
2022-11-14 6:57 ` Hector Martin
2022-11-14 7:03 ` Viresh Kumar
2022-11-14 7:03 ` Viresh Kumar
2022-11-14 11:06 ` Hector Martin
2022-11-14 11:06 ` Hector Martin
2022-10-24 4:39 ` [PATCH v3 5/5] arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103 Hector Martin
2022-10-24 4:39 ` Hector Martin
2022-10-25 16:02 ` Krzysztof Kozlowski
2022-10-25 16:02 ` Krzysztof Kozlowski
2022-10-24 8:28 ` [PATCH v3 0/5] Apple SoC cpufreq driver Marc Zyngier
2022-10-24 8:28 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221025231236.GA3416036-robh@kernel.org \
--to=robh@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.kettenis@xs4all.nl \
--cc=matthias.bgg@gmail.com \
--cc=maz@kernel.org \
--cc=rafael@kernel.org \
--cc=sboyd@kernel.org \
--cc=sven@svenpeter.dev \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.