devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: devi priya <quic_devipriy@quicinc.com>,
	agross@kernel.org, andersson@kernel.org, lgirdwood@gmail.com,
	broonie@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Cc: quic_srichara@quicinc.com, quic_gokulsri@quicinc.com,
	quic_sjaganat@quicinc.com, quic_kathirav@quicinc.com,
	quic_arajkuma@quicinc.com, quic_anusha@quicinc.com,
	quic_poovendh@quicinc.com
Subject: Re: [PATCH 5/6] arm64: dts: qcom: ipq9574: Add cpufreq & RPM related nodes
Date: Fri, 13 Jan 2023 16:32:44 +0100	[thread overview]
Message-ID: <4114bf50-67bf-e11c-5304-f2c6dcc0063d@linaro.org> (raw)
In-Reply-To: <20230113150310.29709-6-quic_devipriy@quicinc.com>



On 13.01.2023 16:03, devi priya wrote:
> Add CPU Freq and RPM related nodes in the device tree
These two are wildly different things, barely related to one
another and can very well be introduced in separate patches.
Please do so.

> 
> Co-developed-by: Praveenkumar I <quic_ipkumar@quicinc.com>
> Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
> Signed-off-by: devi priya <quic_devipriy@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/ipq9574.dtsi | 80 +++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
> index 5a2244b437ed..79fa5d91882c 100644
> --- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
> @@ -9,6 +9,7 @@
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/clock/qcom,gcc-ipq9574.h>
>  #include <dt-bindings/reset/qcom,gcc-ipq9574.h>
> +#include <dt-bindings/clock/qcom,apss-ipq.h>
Please sort the includes alphabetically.

>  
>  / {
>  	interrupt-parent = <&intc>;
> @@ -75,6 +76,10 @@
>  			reg = <0x0>;
>  			enable-method = "psci";
>  			next-level-cache = <&L2_0>;
> +			clocks = <&apcs_glb APCS_ALIAS0_CORE_CLK>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu_opp_table>;
> +			cpu0-supply = <&ipq9574_s1>;
Why is this cpu0-supply and the rest are cpu-supply? Neither of them
seem particularly documented, by the way..


>  		};
>  
>  		CPU1: cpu@1 {
> @@ -83,6 +88,10 @@
>  			reg = <0x1>;
>  			enable-method = "psci";
>  			next-level-cache = <&L2_0>;
> +			clocks = <&apcs_glb APCS_ALIAS0_CORE_CLK>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu_opp_table>;
> +			cpu-supply = <&ipq9574_s1>;
>  		};
>  
>  		CPU2: cpu@2 {
> @@ -91,6 +100,10 @@
>  			reg = <0x2>;
>  			enable-method = "psci";
>  			next-level-cache = <&L2_0>;
> +			clocks = <&apcs_glb APCS_ALIAS0_CORE_CLK>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu_opp_table>;
> +			cpu-supply = <&ipq9574_s1>;
>  		};
>  
>  		CPU3: cpu@3 {
> @@ -99,6 +112,10 @@
>  			reg = <0x3>;
>  			enable-method = "psci";
>  			next-level-cache = <&L2_0>;
> +			clocks = <&apcs_glb APCS_ALIAS0_CORE_CLK>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu_opp_table>;
> +			cpu-supply = <&ipq9574_s1>;
>  		};
>  
>  		L2_0: l2-cache {
> @@ -107,6 +124,42 @@
>  		};
>  	};
>  
> +	cpu_opp_table: opp-table-cpu {
Alphabetically this goes after memory

> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-936000000 {
> +			opp-hz = /bits/ 64 <936000000>;
> +			opp-microvolt = <725000>;
> +			clock-latency-ns = <200000>;
> +		};
Please add a newline between each subnode.

> +		opp-1104000000 {
> +			opp-hz = /bits/ 64 <1104000000>;
> +			opp-microvolt = <787500>;
> +			clock-latency-ns = <200000>;
> +		};
> +		opp-1416000000 {
> +			opp-hz = /bits/ 64 <1416000000>;
> +			opp-microvolt = <862500>;
> +			clock-latency-ns = <200000>;
> +		};
> +		opp-1488000000 {
> +			opp-hz = /bits/ 64 <1488000000>;
> +			opp-microvolt = <925000>;
> +			clock-latency-ns = <200000>;
> +		};
> +		opp-1800000000 {
> +			opp-hz = /bits/ 64 <1800000000>;
> +			opp-microvolt = <987500>;
> +			clock-latency-ns = <200000>;
> +		};
> +		opp-2208000000 {
> +			opp-hz = /bits/ 64 <2208000000>;
> +			opp-microvolt = <1062500>;
> +			clock-latency-ns = <200000>;
> +		};
> +	};
> +
>  	memory@40000000 {
>  		device_type = "memory";
>  		/* We expect the bootloader to fill in the size */
> @@ -128,6 +181,11 @@
>  		#size-cells = <2>;
>  		ranges;
>  
> +		rpm_msg_ram: memory@60000 {
> +			reg = <0x0 0x00060000 0x0 0x6000>;
> +			no-map;
> +		};
> +
>  		tz_region: memory@4a600000 {
>  			reg = <0x0 0x4a600000 0x0 0x400000>;
>  			no-map;
> @@ -324,6 +382,28 @@
>  		};
>  	};
>  
> +	rpm-glink {
> +		compatible = "qcom,glink-rpm";
> +		interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> +		qcom,rpm-msg-ram = <&rpm_msg_ram>;
> +		mboxes = <&apcs_glb 0>;
> +
> +		rpm_requests: glink-channel {
> +			compatible = "qcom,rpm-ipq9574";
> +			qcom,glink-channels = "rpm_requests";
> +
> +			regulators {
> +				compatible = "qcom,rpm-ipq9574-mp5496-regulators";
The regulators are board-specific and should not be included in the
SoC DTSI. If this is a very common configuration, you may split that
into ipq9574-mp5496.dtsi, for example. Or ipq9574-pmics.dtsi if it's
coupled with more PMICs.

> +
> +				ipq9574_s1: s1 {
> +					regulator-min-microvolt = <587500>;
> +					regulator-max-microvolt = <1075000>;
> +					regulator-always-on;
Won't this break CPU retention?

You're holding a vote on it from the CPU devices, so it should be
always enabled when the CPUs are oneline (as far as Linux is
concerned).


Or maybe Linux will think it's enabled and RPM will quietly park
it when it decides it's good to do so.. but will it with an active
request.. not sure, really.. just something to consider..

Konrad
> +				};
> +			};
> +		};
> +	};
> +
>  	timer {
>  		compatible = "arm,armv8-timer";
>  		interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,

  reply	other threads:[~2023-01-13 15:41 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 15:03 [PATCH 0/6] Add regulator support for IPQ9574 SoC devi priya
2023-01-13 15:03 ` [PATCH 1/6] soc: qcom: smd-rpm: Add IPQ9574 compatible devi priya
2023-01-13 16:42   ` Krzysztof Kozlowski
2023-01-16 11:12     ` Mark Brown
2023-01-27 15:57       ` Devi Priya
2023-01-27 15:54     ` Devi Priya
2023-01-13 15:03 ` [PATCH 2/6] dt-bindings: soc: qcom: smd-rpm: Add IPQ9574 compatible string devi priya
2023-01-13 16:43   ` Krzysztof Kozlowski
2023-01-27 15:59     ` Devi Priya
2023-01-13 15:03 ` [PATCH 3/6] regulator: qcom_smd: Add MP5496 regulators devi priya
2023-01-13 15:24   ` Konrad Dybcio
2023-01-27 16:01     ` Devi Priya
2023-01-27 16:03       ` Konrad Dybcio
2023-01-31 10:16         ` Devi Priya
2023-01-13 15:03 ` [PATCH 4/6] regulator: qcom_smd: Add PMIC compatible for IPQ9574 devi priya
2023-01-17 18:38   ` Rob Herring
2023-01-27 16:05     ` Devi Priya
2023-01-27 20:12       ` Rob Herring
2023-01-31 10:22         ` Devi Priya
2023-01-13 15:03 ` [PATCH 5/6] arm64: dts: qcom: ipq9574: Add cpufreq & RPM related nodes devi priya
2023-01-13 15:32   ` Konrad Dybcio [this message]
2023-02-02  9:54     ` Devi Priya
2023-01-13 15:03 ` [PATCH 6/6] regulator: qcom_smd: Add support to define the bootup voltage devi priya
2023-01-13 15:37   ` Konrad Dybcio
2023-01-27 16:07     ` Devi Priya
2023-01-27 16:10       ` Konrad Dybcio
2023-01-31  9:28         ` Devi Priya
2023-01-31 12:44           ` Konrad Dybcio
2023-02-02 11:09             ` Devi Priya
2023-02-02 11:43               ` Konrad Dybcio
2023-02-06 13:48                 ` Devi Priya
2023-01-31  9:37   ` Dmitry Baryshkov
2023-02-02 11:09     ` Devi Priya
2023-02-06 22:30 ` (subset) [PATCH 0/6] Add regulator support for IPQ9574 SoC Bjorn Andersson
2023-02-08  6:09   ` Devi Priya

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=4114bf50-67bf-e11c-5304-f2c6dcc0063d@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_anusha@quicinc.com \
    --cc=quic_arajkuma@quicinc.com \
    --cc=quic_devipriy@quicinc.com \
    --cc=quic_gokulsri@quicinc.com \
    --cc=quic_kathirav@quicinc.com \
    --cc=quic_poovendh@quicinc.com \
    --cc=quic_sjaganat@quicinc.com \
    --cc=quic_srichara@quicinc.com \
    --cc=robh+dt@kernel.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).