Re: [PATCH 7/8] arm64: dts: qcom: msm8939: Define regulator constraints next to usage

From: Bryan O'Donoghue
Date: Wed Jun 14 2023 - 08:51:17 EST


On 14/06/2023 08:16, Stephan Gerhold wrote:
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@xxxxxxxxxxx>


It makes sense to replicate the 8916 change.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>