History log of /openbmc/linux/arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34
# ecbfba69 14-Jun-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: msm8939-pm8916: Mark always-on regulators

Some of the regulators must be always-on to ensure correct operation of
the system, e.g. PM8916 L2 for the LPDDR RAM, L5 for most digital

arm64: dts: qcom: msm8939-pm8916: Mark always-on regulators

Some of the regulators must be always-on to ensure correct operation of
the system, e.g. PM8916 L2 for the LPDDR RAM, L5 for most digital I/O
and L7 for the CPU PLL (strictly speaking the CPU PLL might only need
an active-only vote but this is not supported for regulators in
mainline currently).

The RPM firmware seems to enforce that internally, these supplies stay
on even if we vote for them to power off (and there is no other
processor running). This means it's pointless to keep sending
enable/disable requests because they will just be ignored.
Also, drivers are much more likely to get a wrong impression of the
regulator status, because regulator_is_enabled() will return false when
there are no users, even though the regulator is always on.

Describe this properly by marking the regulators as always-on.

The same changes was already made for MSM8916 in commit 8bbd35771f90
("arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators").

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-8-a3c3ac833567@gerhold.net

show more ...


# 5cdab9a8 14-Jun-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: msm8939: Define regulator constraints next to usage

Right now each MSM8939 device has a huge block of regulator constraints
with allowed voltages for each regulator. For lack of be

arm64: dts: qcom: msm8939: Define regulator constraints next to usage

Right now each MSM8939 device has a huge block of regulator constraints
with allowed voltages for each regulator. For lack of better
documentation these voltages are often copied as-is from the vendor
device tree, without much extra thought.

Unfortunately, the voltages in the vendor device trees are often
misleading or even wrong, e.g. because:

- There is a large voltage range allowed and the actual voltage is
only set somewhere hidden in some messy vendor driver. This is often
the case for pm8916_{l14,l15,l16} because they have a broad range of
1.8-3.3V by default.

- The voltage is actually wrong but thanks to the voltage constraints
in the RPM firmware it still ends up applying the correct voltage.

To have proper regulator constraints it is important to review them in
context of the usage. The current setup in the MSM8939 device trees
makes this quite hard because each device duplicates the standard
voltages for components of the SoC and mixes those with minor
device-specific additions and dummy voltages for completely unused
regulators.

The actual usage of the regulators for the SoC components is in
msm8939-pm8916.dtsi, so it can and should also define the related
voltage constraints. These are not board-specific but defined in the
MSM8939/PM8916 specification. There is no documentation available for
MSM8939 but in practice it's almost identical to MSM8916.

Note that this commit does not make any functional change. All used
regulators still have the same regulator constraints as before. Unused
regulators do not have regulator constraints anymore because most of
these were too broad or even entirely wrong. They should be added back
with proper voltage constraints when there is an actual usage.

The same changes were already made for MSM8916 in commit b0a8f16ae4a0
("arm64: dts: qcom: msm8916: Define regulator constraints next to usage").

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-7-a3c3ac833567@gerhold.net

show more ...


# 88028fa0 14-Jun-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: msm8939-pm8916: Clarify purpose

Add the same comment to msm8939-pm8916.dtsi that was added for the
MSM8916 variant in commit f193264986b5 ("arm64: dts: qcom:
msm8916-pm8916: Clarif

arm64: dts: qcom: msm8939-pm8916: Clarify purpose

Add the same comment to msm8939-pm8916.dtsi that was added for the
MSM8916 variant in commit f193264986b5 ("arm64: dts: qcom:
msm8916-pm8916: Clarify purpose").

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-6-a3c3ac833567@gerhold.net

show more ...


# dce92545 14-Jun-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: msm8939-pm8916: Add missing pm8916_codec supplies

Update for recent changes to pm8916.dtsi in commit 38218822a72f
("arm64: dts: qcom: pm8916: Move default regulator "-supply"s")
an

arm64: dts: qcom: msm8939-pm8916: Add missing pm8916_codec supplies

Update for recent changes to pm8916.dtsi in commit 38218822a72f
("arm64: dts: qcom: pm8916: Move default regulator "-supply"s")
and add the now missing pm8916_codec supplies to msm8939-pm8916.dtsi
as well.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-1-a3c3ac833567@gerhold.net

show more ...


Revision tags: v6.1.33, v6.1.32, v6.1.31
# 835f9395 29-May-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: msm8916/39: Clean up MDSS labels

Right now MDSS related definitions cannot be properly grouped together
in board DTs because the labels do not use consistent prefixes. The DSI
PHY

arm64: dts: qcom: msm8916/39: Clean up MDSS labels

Right now MDSS related definitions cannot be properly grouped together
in board DTs because the labels do not use consistent prefixes. The DSI
PHY label is particularly weird because the DSI number is at the end
(&dsi_phy0) while DSI itself is called &dsi0.

Follow the example of more recent SoCs and give all the MDSS related
nodes a consistent label that allows proper grouping.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-4-bec0f5fb46fb@gerhold.net

show more ...


Revision tags: v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24
# 1e6dfe47 07-Apr-2023 Stephan Gerhold <stephan@gerhold.net>

arm64: dts: qcom: Add msm8939-pm8916.dtsi include

The msm8939-pm8916.dtsi include configures the regulator supplies of
MSM8939 used together with PM8916, as recommended by Qualcomm. In rare
cases wh

arm64: dts: qcom: Add msm8939-pm8916.dtsi include

The msm8939-pm8916.dtsi include configures the regulator supplies of
MSM8939 used together with PM8916, as recommended by Qualcomm. In rare
cases where boards deviate from the recommended design they can just
avoid using this include.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407194905.611461-4-bryan.odonoghue@linaro.org

show more ...