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>