devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).