Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <6525c70a.7b0a0220.3e593.d92d@mx.google.com>
Date:   Tue, 10 Oct 2023 23:50:00 +0200
From:   Christian Marangi <ansuelsmth@gmail.com>
To:     Konrad Dybcio <konrad.dybcio@linaro.org>
Cc:     Robert Marko <robimarko@gmail.com>, ilia.lin@kernel.org,
        vireshk@kernel.org, nm@ti.com, sboyd@kernel.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, agross@kernel.org, andersson@kernel.org,
        rafael@kernel.org, linux-pm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v5 4/4] ARM: dts: qcom: ipq8064: Add CPU OPP table
References: <20230930102218.229613-1-robimarko@gmail.com>
 <20230930102218.229613-4-robimarko@gmail.com>
 <e255dcbd-6342-49e6-9bfe-17a47b2a3c8a@linaro.org>
 <65255c81.050a0220.141f8.7b8f@mx.google.com>
 <1aea4a86-7f7c-46ee-9cbe-655eb7663c2a@linaro.org>
 <6525ad59.1c0a0220.e3509.8545@mx.google.com>
 <3c3c80da-8986-4a8b-8b53-c33b36107e95@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3c3c80da-8986-4a8b-8b53-c33b36107e95@linaro.org>
Precedence: bulk

On Tue, Oct 10, 2023 at 11:17:34PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10/10/23 22:00, Christian Marangi wrote:
> > On Tue, Oct 10, 2023 at 09:52:50PM +0200, Konrad Dybcio wrote:
> > > 
> > > 
> > > On 10/10/23 16:15, Christian Marangi wrote:
> > > > On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
> > > > > 
> > > > > 
> > > > > On 9/30/23 12:21, Robert Marko wrote:
> > > > > > From: Christian Marangi <ansuelsmth@gmail.com>
> > > > > > 
> > > > > > Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> > > > > > Use opp-supported-hw binding to correctly enable and disable the
> > > > > > frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> > > > > > 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> > > > > > 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> > > > > > 
> > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > > > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > > > > > ---
> > > > > Christian/Robert, can you provide a downstream source for this?
> > > > > 
> > > > 
> > > > Sure, consider that everything is with +/-5%.
> > > Hm, so you're e.g. putting ipq8062 384MHz voltage for PVS3 equal to
> > > 0.95*800000 = 760000, but I'm not sure if it's a good idea?
> > > 
> > > The comment in downstream:
> > > 
> > > "These are based on +/-5% Margin on the VDD_APCx that is advertised in our
> > > Datasheet across Temperature"
> > > 
> > > suggests this is already not very accurate, and betting that the lower
> > > threshold works on all chips is probably not the best idea.
> > > 
> > 
> > Consider that everything is driven by the rpm. The original qsdk used the
> > same approach of taking the value, apply +-5% and pass it as a voltage
> > triplet to the rpm regulator. Also the driver have ranges so it
> > autodecide the best voltage in the range of the voltage triplet based on
> > the one supported by the regulator. Normally the normal voltage is
> > always used.
> Eeh? So you pass any half-random value to it and RPM edits it in flight?
> 
> Please be more specific, I'm not very familiar with this platform
> 

Sorry, probably I was a bit confusing.

ipq806x mount on 99% of the devices (this is the suggested design by
qcom) smb208 regulator. These have selector and step since not every
voltage is supported. So the closest one is selected in the range of the
provided min and max.

Most of the time the normal voltage is correctly used by sometimes an
higher one is used. The ranges are described here [1].

Consider that in later version of the qsdk where the moved to DT
definition, they started using OPP v1 where voltage-tollerance binding
is used. The voltage-tollerance was set to 5.

You can find how this value was used for OPPv1 here [2].

As you can see they internally calculate the min and max value and set
them. OPP v2 dropped this and make the dev directly provide min and max.

Effectively we pass the same voltage values.

For the voltage and how it's set, we use cpufreq-dt where if an attached
regulator is found, the set_voltage_triplet is used by providing normal
min and max value and then internally the best value is selected. This
same implementation was used in the qsdk source when they moved to dt
implementation.

Hope it's more clear now how the voltages are set on this platform.
For the RPM part, the voltage is requested but there isn't a direct
control of the system on the regulator since everything is handled by
RPM so there is also that extra step.

[1] https://elixir.bootlin.com/linux/latest/source/drivers/regulator/qcom_rpm-regulator.c#L178
[2] https://elixir.bootlin.com/linux/latest/source/drivers/opp/core.c#L1956
-- 
	Ansuel