devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Andy Gross <agross@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH 3/8] arm64: dts: qcom: msm8916: Fix regulator constraints
Date: Fri, 26 May 2023 16:03:42 +0200	[thread overview]
Message-ID: <ZHC8PhUi0H4o4TUR@gerhold.net> (raw)
In-Reply-To: <cae30437-f9bc-6e7a-8371-bba7eeff1e8f@linaro.org>

On Fri, May 26, 2023 at 02:38:01PM +0100, Bryan O'Donoghue wrote:
> On 17/05/2023 19:48, Stephan Gerhold wrote:
> > The regulator constraints for most MSM8916 devices (except DB410c) were
> > originally taken from Qualcomm's msm-3.10 vendor device tree (for lack
> > of better documentation). Unfortunately it turns out that Qualcomm's
> > voltages are slightly off as well and do not match the voltage
> > constraints applied by the RPM firmware.
> > 
> > This means that we sometimes request a specific voltage but the RPM
> > firmware actually applies a much lower or higher voltage. This is
> > particularly critical for pm8916_l11 which is used as SD card VMMC
> > regulator: The SD card can choose a voltage from the current range of
> > 1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine
> > but the RPM firmware will still silently end up configuring 2.95V.
> > This can be easily reproduced with a multimeter or by checking the
> > SPMI hardware registers of the regulator.
> > 
> > Fix this by making the voltages match the actual "specified range" in
> > the PM8916 Device Specification which is enforced by the RPM firmware.
> > 
> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> > ---
> >   arch/arm64/boot/dts/qcom/msm8916-acer-a1-724.dts           | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts       | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts             | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-gplus-fl8005a.dts         | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-huawei-g7.dts             | 12 ++++++------
> >   arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts       | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts       | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi   | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi    | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts     | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-ufi.dtsi                  | 14 +++++++-------
> >   arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts      | 12 ++++++------
> >   13 files changed, 89 insertions(+), 89 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-acer-a1-724.dts b/arch/arm64/boot/dts/qcom/msm8916-acer-a1-724.dts
> > index 13cd9ad167df..0d517804e44e 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-acer-a1-724.dts
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-acer-a1-724.dts
> > @@ -159,13 +159,13 @@ &smd_rpm_regulators {
> >   	vdd_l7-supply = <&pm8916_s4>;
> >   	s3 {
> > -		regulator-min-microvolt = <1200000>;
> > -		regulator-max-microvolt = <1300000>;
> > +		regulator-min-microvolt = <1250000>;
> > +		regulator-max-microvolt = <1350000>;
> 
> Where are you getting these 5s from ?
> 

I have two explanations for this, one is "documentation", the other is
"experimental testing". You can choose the one you find more convincing. :)

### Documentation ###

For documentation, the S3 range is defined in "PM8916/PM8916-1 Power
Management ICs - Device Specification - LM80-P0436-35 Rev.C - Table 3-16
Regulator high-level summary". The "Specified Range" for this regulator
is 1.25–1.35V.

Also, if you look at typical schematics (e.g. DB410c) you can see that
PM8916 S3 supplies the VDD_xxx_1P3 rails of the WCN3620/WCN3660/WCN3680
chip. Looking at the defined "Operating conditions" in the datasheets of
those they define "Min: 1.25V, Typ: 1.3V, Max: 1.38V". As such, 1.2V is
not even a valid voltage for the actual usage of this regulator.

### Experimental Testing ###

The reason why it still works in practice is that the RPM firmware does
not let you apply invalid voltages here. With experimental testing
I observed that it keeps the voltage always in the "Specified Range"
of 1.25–1.35V.

You can reproduce this easily by adding the SPMI regulators in
pm8916.dtsi. These represent the actual regulator hardware registers:

diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index 864bb1cd68db..22ab0f59be4a 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -177,5 +177,9 @@ wcd_codec: audio-codec@f000 {
 			#sound-dai-cells = <1>;
 			status = "disabled";
 		};
+
+		regulators {
+			compatible = "qcom,pm8916-regulators";
+		};
 	};
 };

With this each of the regulators will show up twice in /sys/class/regulator.
Once the RPM version and once the SPMI version. If you check the
/sys/class/regulator/.../microvolts of the SPMI variant you can see the
actual voltage that was applied by the RPM firmware.

For example, if you think that 1.2V is really possible then try:

	s3 {
		regulator-min-microvolt = <1200000>;
		regulator-max-microvolt = <1200000>;
	};

In sysfs you will almost certainly see that the SPMI regulator is
actually configured with 1.25V by the RPM firmware. It does not allow
setting anything lower.

> >   	};
> >   	s4 {
> > -		regulator-min-microvolt = <1800000>;
> > -		regulator-max-microvolt = <2100000>;
> > +		regulator-min-microvolt = <1850000>;
> > +		regulator-max-microvolt = <2150000>;
> >   	};
> >   	l1 {
> > @@ -199,7 +199,7 @@ l7 {
> >   	};
> >   	l8 {
> > -		regulator-min-microvolt = <2850000>;
> > +		regulator-min-microvolt = <2900000>;
> >   		regulator-max-microvolt = <2900000>;
> >   	};
> > @@ -209,12 +209,12 @@ l9 {
> >   	};
> >   	l10 {
> > -		regulator-min-microvolt = <2700000>;
> > +		regulator-min-microvolt = <2800000>;
> >   		regulator-max-microvolt = <2800000>;
> >   	};
> >   	l11 {
> > -		regulator-min-microvolt = <1800000>;
> > +		regulator-min-microvolt = <2950000>;
> 
> Wouldn't 1v8 be the right voltage for eMMC !SD though have you tested eMMC
> instead of SD ?
> 

This is the supply voltage (not I/O voltage) which is also 2.9V for the
eMMC typically. But the point here is that only 2.95V can be set for
this regulator on most RPM firmware versions.

It does not matter what you connect there. I tried setting

	l11 {
		regulator-min-microvolt = <1800000>;
		regulator-max-microvolt = <1800000>;
	};

but the RPM firmware still applies 2.95V. In this case I even verified
this with a multimeter. The regulator is always 2.95V, even if you ask
the RPM firmware to apply 1.8V.

Thanks,
Stephan

  reply	other threads:[~2023-05-26 14:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17 18:48 [PATCH 0/8] arm64: dts: qcom: msm8916: Rework regulator constraints Stephan Gerhold
2023-05-17 18:48 ` [PATCH 1/8] arm64: dts: qcom: apq8016-sbc: Fix " Stephan Gerhold
2023-05-17 18:48 ` [PATCH 2/8] arm64: dts: qcom: apq8016-sbc: Fix 1.8V power rail on LS expansion Stephan Gerhold
2023-05-17 18:48 ` [PATCH 3/8] arm64: dts: qcom: msm8916: Fix regulator constraints Stephan Gerhold
2023-05-26 13:38   ` Bryan O'Donoghue
2023-05-26 14:03     ` Stephan Gerhold [this message]
2023-05-26 15:42   ` Bryan O'Donoghue
2023-05-26 15:43   ` Bryan O'Donoghue
2023-05-17 18:48 ` [PATCH 4/8] arm64: dts: qcom: msm8916: Disable audio codecs by default Stephan Gerhold
2023-05-17 18:48 ` [PATCH 5/8] arm64: dts: qcom: pm8916: Move default regulator "-supply"s Stephan Gerhold
2023-05-17 18:48 ` [PATCH 6/8] arm64: dts: qcom: msm8916-pm8916: Clarify purpose Stephan Gerhold
2023-05-17 18:48 ` [PATCH 7/8] arm64: dts: qcom: msm8916: Define regulator constraints next to usage Stephan Gerhold
2023-05-25 23:35   ` Konrad Dybcio
2023-05-26  6:47     ` Stephan Gerhold
2023-05-26 21:11       ` Konrad Dybcio
2023-05-27  9:22         ` Stephan Gerhold
2023-05-17 18:48 ` [PATCH 8/8] arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators Stephan Gerhold
2023-05-25 23:39   ` Konrad Dybcio
2023-05-26  0:28     ` Konrad Dybcio
2023-05-26  6:36       ` Stephan Gerhold
2023-05-26  8:50         ` Konrad Dybcio
2023-05-26 12:55           ` Stephan Gerhold
2023-05-25  4:54 ` [PATCH 0/8] arm64: dts: qcom: msm8916: Rework regulator constraints Bjorn Andersson

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=ZHC8PhUi0H4o4TUR@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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).