Received-SPF: pass (google.com: domain of linux-kernel+bounces-47623-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAA8EJpoMXkAd3EBf=p+nig8VWzY9tiUAWhfGJn3XOX1uSa=22Q@mail.gmail.com>
 <20240201040020.73949-1-amadeus@jmu.edu.cn>
In-Reply-To: <20240201040020.73949-1-amadeus@jmu.edu.cn>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Thu, 1 Feb 2024 06:38:17 +0200
Message-ID: <CAA8EJpoQ8O_atu9K=eG+NLQ_Ei64qvcQ6GoYyJjxJ_DGH2D2+Q@mail.gmail.com>
Subject: Re: [PATCH 1/3] arm64: dts: qcom: ipq6018: separate CPU OPP tables
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: andersson@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, 
	konrad.dybcio@linaro.org, krzysztof.kozlowski+dt@linaro.org, 
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	robh+dt@kernel.org
Content-Type: text/plain; charset="UTF-8"

On Thu, 1 Feb 2024 at 06:00, Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> Hi, Dmitry
> > Straight to the board files, please, no need for additional includes.
>
> Is it possible to move the mp5496 node to mp5496.dtsi?
> Because ipq9574 also uses this mp5496 pmic.
>
> &rpm_requests {
>         regulators {
>                 compatible = "qcom,rpm-mp5496-regulators";
>
>                 mp5496_s1: s1 {
>                         regulator-min-microvolt = <725000>;
>                         regulator-max-microvolt = <1075000>;
>                         status = "disabled";
>                 };
>
>                 mp5496_s2: s2 {
>                         regulator-min-microvolt = <725000>;
>                         regulator-max-microvolt = <1062500>;
>                         status = "disabled";
>                 };
>
>                 mp5496_l2: l2 {
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <3300000>;
>                         status = "disabled";
>                 };
>         };
> };

Usually this is a bad idea, the regulator boundaries are board specific.

>
> > From your patches I had the feeling that you still want to limit the
> > high-frequency OPP entries if there is no PMIC.
>
> Sorry for this misunderstanding, the cpu max frequency is determined
> by the cpu_speed_bin. It's just that the efuse of the board I have
> without pmic are all 1.2GHz.

Ack, sounds good then.

-- 
With best wishes
Dmitry