arm64: dts: qcom: pm8916: Rename &wcd_codec -> &pm8916_codec

All definitions in pm8916.dtsi use the &pm8916_ label prefix, only the
codec uses the &wcd_codec label. &wcd_codec is confusing because t

arm64: dts: qcom: pm8916: Rename &wcd_codec -> &pm8916_codec

All definitions in pm8916.dtsi use the &pm8916_ label prefix, only the
codec uses the &wcd_codec label. &wcd_codec is confusing because the
codec on MSM8916 is split into a "wcd-digital" and "wcd-analog" part
and both could be described with &wcd_codec.

Let's just name it &pm8916_codec so it's consistent with all other PMIC
device nodes.

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/20230525-msm8916-labels-v1-5-bec0f5fb46fb@gerhold.net

show more ...

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 ...

arm64: dts: qcom: msm8916-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: msm8916-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.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-8-54d4960a05fc@gerhold.net

show more ...

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

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

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

Right now each MSM8916 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 MSM8916 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
msm8916-pm8916.dtsi, so it can and should also define the related
voltage constraints. These are not board-specific but defined in the
APQ8016E/PM8916 Device Specification. The board DT can then focus on
describing the actual board-specific regulators, which makes it much
easier to review and spot potential mistakes there.

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.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-7-54d4960a05fc@gerhold.net

show more ...

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

Goal of the msm8916-pm8916.dtsi is to reduce the boilerplate necessary
to create a device tree for a typical board with the MSM8916 SoC
combined wit

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

Goal of the msm8916-pm8916.dtsi is to reduce the boilerplate necessary
to create a device tree for a typical board with the MSM8916 SoC
combined with the PM8916 PMIC. > 99% of all MSM8916 boards use the same
standard setup where many of the PM8916 regulators have a fixed purpose
and only some are left up for board-specific use.

While MSM8916 (and perhaps MSM8939 soon) is currently the only platform
with such an include, it has definitely proven useful. With more than
30 boards using it (not all of them upstream yet) it simplifies the
review a lot and reduces the chance of configuring the standard
components incorrectly.

In preparation of extending its scope slightly, add a comment at the
top that clearly explains what the .dtsi represents and when it should
(or should not) be used.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-6-54d4960a05fc@gerhold.net

show more ...

arm64: dts: qcom: pm8916: Move default regulator "-supply"s

Some of the power supplies for the analog audio codec in PM8916 are
wired externally. While most boards use the regulators currently
speci

arm64: dts: qcom: pm8916: Move default regulator "-supply"s

Some of the power supplies for the analog audio codec in PM8916 are
wired externally. While most boards use the regulators currently
specified in pm8916.dtsi, in theory it could be connected differently.

We already have msm8916-pm8916.dtsi that models that standard setup
used by most devices so move the -supply properties there and keep
the base pm8916.dtsi independent.

Currently all MSM8916 boards in mainline make use of
msm8916-pm8916.dtsi, so it is not necessary to adjust any other boards.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-5-54d4960a05fc@gerhold.net

show more ...

arm64: dts: qcom: msm8916: Move WCN compatible to boards

On MSM8916 the wireless connectivity functionality (WiFi/Bluetooth) is
split into the digital part inside the SoC and the analog RF part insi

arm64: dts: qcom: msm8916: Move WCN compatible to boards

On MSM8916 the wireless connectivity functionality (WiFi/Bluetooth) is
split into the digital part inside the SoC and the analog RF part inside
a supplementary WCN36xx chip. For MSM8916, three different options
exist:

- WCN3620 (WLAN 802.11 b/g/n 2.4 GHz + Bluetooth)
- WCN3660B (WLAN 802.11 a/b/g/n 2.4/5 GHz + Bluetooth)
- WCN3680B (WLAN 802.11ac 2.4/5 GHz + Bluetooth)

Choosing one of these is up to the board vendor. This means that the
compatible belongs into the board-specific DT part so people porting
new boards pay attention to set the correct compatible.

Right now msm8916.dtsi sets "qcom,wcn3620" as default compatible,
which does not work at all for boards that have WCN3660B or WCN3680B.

Remove the default compatible from msm8196.dtsi and move it to the board
DT as follows:

- Boards with only &pronto { status = "okay"; } used the default
"qcom,wcn3620" so far. They now set this explicitly for &wcnss_iris.
- Boards with &pronto { ... iris { compatible = "qcom,wcn3660b"; }};
already had an override that just moves to &wcnss_iris now.
- For msm8916-samsung-a2015-common.dtsi the WCN compatible differs for
boards making use of it (a3u: wcn3620, a5u: wcn3660b, e2015: wcn3620)
so the definitions move to the board-specific DT part.

Since this requires touching all the board DTs, use this as a chance to
name the WCNSS-related labels consistently, so everything is grouped
properly when sorted alphabetically.

No functional change, just clean-up for more clarity & easier porting.
Aside from ordering the generated DTBs are identical.

Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230309091452.1011776-1-stephan.gerhold@kernkonzept.com

show more ...

arm64: dts: qcom: align RPM regulators node name with bindings

Node names should be generic and new DT schema expects RPM regulators
node to be just "regulators".

Signed-off-by: Krzysztof Kozlowski

arm64: dts: qcom: align RPM regulators node name with bindings

Node names should be generic and new DT schema expects RPM regulators
node to be just "regulators".

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220926092104.111449-3-krzysztof.kozlowski@linaro.org

show more ...

arm64: dts: qcom: msm8916-pm8916: Stop using s1/l3 as regulators

s1 (VDDCX) and l3 (VDDMX) are now managed by rpmpd as power domains.
This allows us to vote for voltage corners instead of voting for

arm64: dts: qcom: msm8916-pm8916: Stop using s1/l3 as regulators

s1 (VDDCX) and l3 (VDDMX) are now managed by rpmpd as power domains.
This allows us to vote for voltage corners instead of voting for raw
voltages. But we cannot manage these as regulator and power domain at
the same time: The votes by rpmpd would conflict with the ones from
the regulator driver.

All users of these regulators have been converted to power domains.
Make sure that no new users are added by removing s1 and l3 from
the regulator definitions.

This also allows us to remove the arbitrary voltage constraints
we have been using for these regulators. Not all of the voltages
listed there would actually have been safe for the boards.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-11-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

arm64: dts: qcom: msm8916: Use power domains for MSS/WCNSS remoteprocs

So far we have been making proxy votes for the remote processors
through the regulator interface. Now that we have rpmpd it's b

arm64: dts: qcom: msm8916: Use power domains for MSS/WCNSS remoteprocs

So far we have been making proxy votes for the remote processors
through the regulator interface. Now that we have rpmpd it's better
to vote for performance states through the power domain interface.

This also allows us to move these supplies back to msm8916.dtsi
because the device tree binding for RPMPD is independent of the
underlying regulator/PMIC.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-10-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

arm64: dts: qcom: msm8916: Move more supplies to msm8916-pm8916.dtsi

So far we had some supplies defined for all boards in msm8916.dtsi,
while others were duplicated into every board-specific device

arm64: dts: qcom: msm8916: Move more supplies to msm8916-pm8916.dtsi

So far we had some supplies defined for all boards in msm8916.dtsi,
while others were duplicated into every board-specific device tree.

Now that we have msm8916-pm8916.dtsi as a common include for all
standard MSM8916 devices using PM8916, move the remaining common
supplies to msm8916-pm8916.dtsi to reduce duplication a bit.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-9-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

arm64: dts: qcom: msm8916: Move PM8916-specific parts to msm8916-pm8916.dtsi

Device trees for newer SoCs avoid defining the regulator nodes directly
in the SoC device tree (here: msm8916.dtsi). The

arm64: dts: qcom: msm8916: Move PM8916-specific parts to msm8916-pm8916.dtsi

Device trees for newer SoCs avoid defining the regulator nodes directly
in the SoC device tree (here: msm8916.dtsi). The reason for this is that
theoretically it is possible to combine the SoC with a different PMIC,
or to use all the regulators in a board-specific way.

Therefore let's remove those from the SoC include (msm8916.dtsi).

In practice, pretty much all MSM8916 boards were combined with PM8916,
and use the regulators in similar ways. After looking at many different
MSM8916 boards (mostly smartphones and tablets), I haven't seen a single
device that isn't using the same regulators for components integrated
into the SoC.

If all boards end up defining all regulators and supplies in the same way
then it is useful to have an include for that, so we can avoid duplicating
it everywhere. If there is really a super special board that does it
differently it could just override some properties or avoid using the
include altogether.

This patch moves the regulator and common supply definitions to
a new include called "msm8916-pm8916.dtsi".

This is also going to be useful when introducing CPR (Core Power
Reduction) later because we can configure the CPU regulator
(pm8916_spmi_s2) for all devices in this common include.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-8-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

arm64: dts: qcom: msm8916: Move more supplies to msm8916-pm8916.dtsi

So far we had some supplies defined for all boards in msm8916.dtsi,
while others were duplicated into every board-spe

arm64: dts: qcom: msm8916: Move more supplies to msm8916-pm8916.dtsi

So far we had some supplies defined for all boards in msm8916.dtsi,
while others were duplicated into every board-specific device tree.

Now that we have msm8916-pm8916.dtsi as a common include for all
standard MSM8916 devices using PM8916, move the remaining common
supplies to msm8916-pm8916.dtsi to reduce duplication a bit.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-9-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

arm64: dts: qcom: msm8916: Move PM8916-specific parts to msm8916-pm8916.dtsi

Device trees for newer SoCs avoid defining the regulator nodes directly
in the SoC device tree (here: msm8916

arm64: dts: qcom: msm8916: Move PM8916-specific parts to msm8916-pm8916.dtsi

Device trees for newer SoCs avoid defining the regulator nodes directly
in the SoC device tree (here: msm8916.dtsi). The reason for this is that
theoretically it is possible to combine the SoC with a different PMIC,
or to use all the regulators in a board-specific way.

Therefore let's remove those from the SoC include (msm8916.dtsi).

In practice, pretty much all MSM8916 boards were combined with PM8916,
and use the regulators in similar ways. After looking at many different
MSM8916 boards (mostly smartphones and tablets), I haven't seen a single
device that isn't using the same regulators for components integrated
into the SoC.

If all boards end up defining all regulators and supplies in the same way
then it is useful to have an include for that, so we can avoid duplicating
it everywhere. If there is really a super special board that does it
differently it could just override some properties or avoid using the
include altogether.

This patch moves the regulator and common supply definitions to
a new include called "msm8916-pm8916.dtsi".

This is also going to be useful when introducing CPR (Core Power
Reduction) later because we can configure the CPU regulator
(pm8916_spmi_s2) for all devices in this common include.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200720085406.6716-8-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...