From: Rob Herring <robh@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Yangtao Li <tiny.windzz@gmail.com>,
Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Stephen Boyd <sboyd@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-sunxi@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
Brandon Cheo Fusi <fusibrandon13@gmail.com>,
Martin Botka <martin.botka@somainline.org>,
Martin Botka <martin.botka1@gmail.com>
Subject: Re: [PATCH v2 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
Date: Wed, 20 Mar 2024 10:02:28 -0500 [thread overview]
Message-ID: <20240320150228.GA1705913-robh@kernel.org> (raw)
In-Reply-To: <20240318011228.2626-4-andre.przywara@arm.com>
On Mon, Mar 18, 2024 at 01:12:23AM +0000, Andre Przywara wrote:
> From: Martin Botka <martin.botka@somainline.org>
>
> The Allwinner H616 uses a similar NVMEM based mechanism to determine the
> silicon revision, which is required to select the right frequency /
> voltage pair for the OPPs.
> However it limits the maximum frequency for some speedbins, which
> requires to introduce the opp-supported-hw property.
>
> Add this property to the list of allowed properties, also drop the
> requirement for the revision specific opp-microvolt properties, since
> they won't be needed if using opp-supported-hw. When using this
> property, we also might have multiple OPP nodes per frequency, so relax
> the OPP node naming to allow a single letter suffix.
>
> Also use to opportunity to adjust some wording, and drop a sentence
> referring to the Linux driver and the OPP subsystem.
>
> Shorten the existing example and add another example, showcasing the
> opp-supported-hw property.
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../allwinner,sun50i-h6-operating-points.yaml | 89 ++++++++++---------
> 1 file changed, 47 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> index 51f62c3ae1947..d5439a3f696bc 100644
> --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> @@ -13,25 +13,25 @@ maintainers:
> description: |
> For some SoCs, the CPU frequency subset and voltage value of each
> OPP varies based on the silicon variant in use. Allwinner Process
> - Voltage Scaling Tables defines the voltage and frequency value based
> - on the speedbin blown in the efuse combination. The
> - sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
> - provide the OPP framework with required information.
> + Voltage Scaling Tables define the voltage and frequency values based
> + on the speedbin blown in the efuse combination.
>
> allOf:
> - $ref: opp-v2-base.yaml#
>
> properties:
> compatible:
> - const: allwinner,sun50i-h6-operating-points
> + enum:
> + - allwinner,sun50i-h6-operating-points
> + - allwinner,sun50i-h616-operating-points
>
> nvmem-cells:
> description: |
> A phandle pointing to a nvmem-cells node representing the efuse
> - registers that has information about the speedbin that is used
> + register that has information about the speedbin that is used
> to select the right frequency/voltage value pair. Please refer
> - the for nvmem-cells bindings
> - Documentation/devicetree/bindings/nvmem/nvmem.txt and also
> + to the nvmem-cells bindings in
> + Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
> examples below.
>
> opp-shared: true
> @@ -41,21 +41,23 @@ required:
> - nvmem-cells
>
> patternProperties:
> - "^opp-[0-9]+$":
> + "^opp-[0-9]+(-[a-z])?$":
> type: object
>
> properties:
> opp-hz: true
> clock-latency-ns: true
> + opp-microvolt: true
> + opp-supported-hw:
> + description: |
> + A single 32 bit bitmap value, representing compatible HW, one
> + bit per speed bin index.
>
> patternProperties:
> "^opp-microvolt-speed[0-9]$": true
>
> required:
> - opp-hz
> - - opp-microvolt-speed0
> - - opp-microvolt-speed1
> - - opp-microvolt-speed2
>
> unevaluatedProperties: false
>
> @@ -77,58 +79,61 @@ examples:
> opp-microvolt-speed2 = <800000>;
> };
>
> - opp-720000000 {
> + opp-1080000000 {
> clock-latency-ns = <244144>; /* 8 32k periods */
> - opp-hz = /bits/ 64 <720000000>;
> + opp-hz = /bits/ 64 <1080000000>;
>
> - opp-microvolt-speed0 = <880000>;
> - opp-microvolt-speed1 = <820000>;
> - opp-microvolt-speed2 = <800000>;
> + opp-microvolt-speed0 = <1060000>;
> + opp-microvolt-speed1 = <880000>;
> + opp-microvolt-speed2 = <840000>;
> };
>
> - opp-816000000 {
> + opp-1488000000 {
> clock-latency-ns = <244144>; /* 8 32k periods */
> - opp-hz = /bits/ 64 <816000000>;
> + opp-hz = /bits/ 64 <1488000000>;
>
> - opp-microvolt-speed0 = <880000>;
> - opp-microvolt-speed1 = <820000>;
> - opp-microvolt-speed2 = <800000>;
> + opp-microvolt-speed0 = <1160000>;
> + opp-microvolt-speed1 = <1000000>;
> + opp-microvolt-speed2 = <960000>;
> };
> + };
> +
> + - |
> + opp-table {
> + compatible = "allwinner,sun50i-h616-operating-points";
> + nvmem-cells = <&speedbin_efuse>;
> + opp-shared;
>
> - opp-888000000 {
> + opp-480000000 {
> clock-latency-ns = <244144>; /* 8 32k periods */
> - opp-hz = /bits/ 64 <888000000>;
> + opp-hz = /bits/ 64 <480000000>;
>
> - opp-microvolt-speed0 = <940000>;
> - opp-microvolt-speed1 = <820000>;
> - opp-microvolt-speed2 = <800000>;
> + opp-microvolt = <900000>;
> + opp-supported-hw = <0x1f>;
> };
>
> - opp-1080000000 {
> + opp-792000000-l {
> clock-latency-ns = <244144>; /* 8 32k periods */
> - opp-hz = /bits/ 64 <1080000000>;
> + opp-hz = /bits/ 64 <792000000>;
>
> - opp-microvolt-speed0 = <1060000>;
> - opp-microvolt-speed1 = <880000>;
> - opp-microvolt-speed2 = <840000>;
> + opp-microvolt = <900000>;
> + opp-supported-hw = <0x02>;
> };
>
> - opp-1320000000 {
> + opp-792000000-h {
> clock-latency-ns = <244144>; /* 8 32k periods */
> - opp-hz = /bits/ 64 <1320000000>;
> + opp-hz = /bits/ 64 <792000000>;
>
> - opp-microvolt-speed0 = <1160000>;
> - opp-microvolt-speed1 = <940000>;
> - opp-microvolt-speed2 = <900000>;
> + opp-microvolt = <940000>;
> + opp-supported-hw = <0x10>;
So far, we've avoided multiple entries for a single frequency. I think
it would be good to maintain that.
Couldn't you just do:
opp-supported-hw = <0>, <0x10>, <0x02>;
Where the index corresponds to speed0, speed1, speed2.
If not, then I don't understand how multiple entries of opp-supported-hw
are supposed to work.
Rob
next prev parent reply other threads:[~2024-03-20 15:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 1:12 [PATCH v2 0/8] cpufreq: sun50i: Add Allwinner H616 support Andre Przywara
2024-03-18 1:12 ` [PATCH v2 1/8] firmware: smccc: Export revision soc_id function Andre Przywara
2024-03-18 1:12 ` [PATCH v2 2/8] cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs Andre Przywara
2024-03-18 1:12 ` [PATCH v2 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw Andre Przywara
2024-03-20 15:02 ` Rob Herring [this message]
2024-03-20 15:37 ` Andre Przywara
2024-03-21 3:09 ` Viresh Kumar
2024-03-26 11:02 ` Andre Przywara
2024-03-18 1:12 ` [PATCH v2 4/8] cpufreq: sun50i: Refactor speed bin decoding Andre Przywara
2024-03-18 1:12 ` [PATCH v2 5/8] cpufreq: sun50i: Add support for opp_supported_hw Andre Przywara
2024-03-18 1:12 ` [PATCH v2 6/8] cpufreq: sun50i: Add H616 support Andre Przywara
2024-03-18 1:12 ` [PATCH v2 7/8] arm64: dts: allwinner: h616: Add CPU OPPs table Andre Przywara
2024-03-18 1:12 ` [PATCH v2 8/8] arm64: dts: allwinner: h616: enable DVFS for all boards Andre Przywara
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=20240320150228.GA1705913-robh@kernel.org \
--to=robh@kernel.org \
--cc=andre.przywara@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fusibrandon13@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=martin.botka1@gmail.com \
--cc=martin.botka@somainline.org \
--cc=nm@ti.com \
--cc=rafael@kernel.org \
--cc=samuel@sholland.org \
--cc=sboyd@kernel.org \
--cc=tiny.windzz@gmail.com \
--cc=vireshk@kernel.org \
--cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).