Stephan Gerhold [Wed, 17 May 2023 18:48:47 +0000 (20:48 +0200)]
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.
Stephan Gerhold [Wed, 17 May 2023 18:48:46 +0000 (20:48 +0200)]
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.
Stephan Gerhold [Wed, 17 May 2023 18:48:45 +0000 (20:48 +0200)]
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.
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.
Stephan Gerhold [Wed, 17 May 2023 18:48:43 +0000 (20:48 +0200)]
arm64: dts: qcom: msm8916: Disable audio codecs by default
Not every device has something connected to the digital audio codec
in MSM8916 and/or the analog audio codec in PM8916. Disable those by
default so the hardware is only powered up when necessary.
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.
Stephan Gerhold [Wed, 17 May 2023 18:48:41 +0000 (20:48 +0200)]
arm64: dts: qcom: apq8016-sbc: Fix 1.8V power rail on LS expansion
The 96Boards specification expects a 1.8V power rail on the low-speed
expansion connector that is able to provide at least 0.18W / 100 mA.
According to the DB410c hardware user manual this is done by connecting
both L15 and L16 in parallel with up to 55mA each (for 110 mA total) [1].
Unfortunately the current regulator setup in the DB410c device tree
does not implement the specification correctly and only provides 5 mA:
- Only L15 is marked always-on, so L16 is never enabled.
- Without specifying a load the regulator is put into LPM where
it can only provide 5 mA.
Fix this by:
- Adding proper voltage constraints for L16.
- Making L16 always-on.
- Adding regulator-system-load for both L15 and L16. 100 mA should be
available in total, so specify 50 mA for each. (The regulator
hardware can only be in normal (55 mA) or low-power mode (5 mA) so
this will actually result in the expected 110 mA total...)
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Fixes: 828dd5d66f0f ("arm64: dts: apq8016-sbc: make 1.8v available on LS expansion") 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-2-54d4960a05fc@gerhold.net
For some reason DB410c has completely bogus regulator constraints that
actually just correspond to the programmable voltages which are already
provided by the regulator driver. Some of them are not just outside the
recommended operating conditions of the APQ8016E SoC but even exceed
the absolute maximum ratings, potentially risking permanent device
damage.
In practice it's not quite as dangerous thanks to the RPM firmware:
It turns out that it has its own voltage constraints and silently
clamps all regulator requests. For example, requesting 3.3V for L5
(allowed by the current regulator constraints!) still results in 1.8V
being programmed in the actual regulator hardware.
Experimentation with various voltages shows that the internal RPM
voltage constraints roughly correspond to the safe "specified range"
in the PM8916 Device Specification (rather than the "programmable
range" used inside apq8016-sbc.dtsi right now).
Combine those together with some fixed voltages used in the old
msm-3.10 device tree from Qualcomm to give DB410c some actually valid
voltage constraints.
arm64: dts: qcom: sm8550: enable DISPCC by default
Enable the Display Clock Controller by default in SoC DTSI so unused
clocks can be turned off. It does not require any external resources,
so as core SoC component should be always available to boards.
Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230516154539.238655-1-krzysztof.kozlowski@linaro.org
Nikita Travkin [Mon, 15 May 2023 09:37:42 +0000 (14:37 +0500)]
arm64: dts: qcom: sc7180: Drop redundant disable in mdp
mdss is useless without a display controller which makes explicitly
enabling mdp redundant. Have it enabled by default to drop the extra
node for all users.
Signed-off-by: Nikita Travkin <nikita@trvn.ru> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230515093744.289045-3-nikita@trvn.ru
Nikita Travkin [Mon, 15 May 2023 09:37:41 +0000 (14:37 +0500)]
arm64: dts: qcom: sc7180: Don't enable lpass clocks by default
lpass clocks are usually blocked from HLOS by the firmware and
instead are managed by the ADSP. Mark them as reserved and explicitly
enable in the CrOS boards that have special, cooperative firmware.
The IDP board gets lpass clocks disabled as it doesn't make use of sound
anyway and might use Qualcomm firmware that blocks those clocks. [1]
Yang Xiwen [Fri, 5 May 2023 16:32:51 +0000 (00:32 +0800)]
arm64: dts: qcom: msm8916-ufi: make UDC dual mode
It's possible to use this device with a (non-standard) hub to get USB
working in host mode, but dr_mode="peripheral" prevents the UDC to
do so.
Remove dr_mode="peripheral" and add usb-role-switch so that it defaults
to otg mode and can be switched to host mode in userspace.
MSM8953 has two DMA controllers for the various I2C, SPI and UART
busses. Add the nodes and configure all the I2C nodes so that the driver
can use the DMA.
arm64: dts: qcom: sdm630: correct camss unit address
Match unit-address to reg entry to fix dtbs W=1 warnings:
Warning (simple_bus_reg): /soc/camss@ca00000: simple-bus unit address format error, expected "ca00020"
Fixes: f3d5d3cc6971 ("arm64: dts: qcom: sdm630: Configure the camera subsystem") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230419211856.79332-10-krzysztof.kozlowski@linaro.org
arm64: dts: qcom: msm8976: correct MMC unit address
Match unit-address to reg entry to fix dtbs W=1 warnings:
Warning (simple_bus_reg): /soc@0/mmc@7824000: simple-bus unit address format error, expected "7824900"
Warning (simple_bus_reg): /soc@0/mmc@7864000: simple-bus unit address format error, expected "7864900"
Warning (simple_bus_reg): /soc@0/mmc@7a24000: simple-bus unit address format error, expected "7a24900"
Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230419211856.79332-7-krzysztof.kozlowski@linaro.org
arm64: dts: qcom: msm8916: correct MMC unit address
Match unit-address to reg entry to fix dtbs W=1 warnings:
Warning (simple_bus_reg): /soc@0/mmc@7824000: simple-bus unit address format error, expected "7824900"
Warning (simple_bus_reg): /soc@0/mmc@7864000: simple-bus unit address format error, expected "7864900"
Konrad Dybcio [Tue, 11 Apr 2023 18:14:43 +0000 (20:14 +0200)]
arm64: dts: qcom: sm8150-kumano: Set up camera fixed regulators
Sony - as per usual - used a whole bunch of GPIO-gated fixed
voltage regulators for camera sensors on Kumano. Describe them
and the corresponding pins.
Konrad Dybcio [Tue, 11 Apr 2023 18:14:42 +0000 (20:14 +0200)]
arm64: dts: qcom: sm8150-kumano: Add GPIO line names for TLMM
Sony ever so graciously provides GPIO line names in their downstream
kernel (though sometimes they are not 100% accurate and you can judge
that by simply looking at them and with what drivers they are used).
Add these to the common DTSI to better document the hardware.
The pin assignment for TLMM is identical on both devices. Great job!
Konrad Dybcio [Tue, 11 Apr 2023 18:14:41 +0000 (20:14 +0200)]
arm64: dts: qcom: sm8150-kumano: Add GPIO line names for PMIC GPIOs
Sony ever so graciously provides GPIO line names in their downstream
kernel (though sometimes they are not 100% accurate and you can judge
that by simply looking at them and with what drivers they are used).
Add these to the Griffin and Bahamut device trees to better document
the hardware.
arm64: dts: qcom: pm8998: don't use GIC_SPI for SPMI interrupts
Unlike typical GIC interrupts, first cell for SPMI interrupts is the
USID rather than GIC_SPI/GIC_PPI/GIC_LPI qualifier. Fix the resin
interrupt to use USID value 0x0 rather than GIC_SPI define.
Fixes: f86ae6f23a9e ("arm64: dts: qcom: sagit: add initial device tree for sagit") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230409182145.122895-1-dmitry.baryshkov@linaro.org
Andrew Halaney [Mon, 1 May 2023 21:24:46 +0000 (16:24 -0500)]
arm64: dts: qcom: sa8155p-adp: Move mtl nodes into ethernet node
The mtl nodes aren't evaluated unless they're under the node with the
compatible. Move them so they're now evaluated in case future patchsets
modify them incorrectly.
Bhupesh Sharma [Tue, 2 May 2023 09:39:58 +0000 (15:09 +0530)]
arm64: dts: qcom: sc7280: Fix EUD dt node syntax
As noted by Konrad while reviewing [1], fix the EUD and DWC3
node syntax in sc7280 dtsi file.
While at it also fix the errors reported by '$ make dtbs_check'
for the EUD node:
arch/arm64/boot/dts/qcom/sc7280-crd-r3.dtb: eud@88e0000: ports:
'oneOf' conditional failed, one must be fixed:
'port' is a required property
'#address-cells' is a required property
'#size-cells' is a required property
From schema: Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
arm64: dts: qcom: enable dual ("bonded") DSI mode for DB845c
Now as both lt9611 and drm/msm drivers were updated to handle the 4k
modes over DSI, enable "bonded" DSI mode on DB845c. This way the board
utilizes both DSI links and thus can support 4k on the HDMI output.
With support for the QMP combo phy to react to USB Type-C switch events,
introduce it as the next hop for the SuperSpeed lanes of the Type-C
connector, and connect the output of the DisplayPort controller
to the QMP combo phy.
This allows the TCPM to perform orientation switching of both USB and
DisplayPort signals.
With support for the QMP combo phy to react to USB Type-C switch events,
introduce it as the next hop for the SuperSpeed lanes of the Type-C
connector, and connect the output of the DisplayPort controller
to the QMP combo phy.
This allows the TCPM to perform orientation switching of both USB and
DisplayPort signals.
Bjorn Andersson [Mon, 15 May 2023 03:27:42 +0000 (20:27 -0700)]
arm64: dts: qcom: sc8280xp-crd: Add QMP to SuperSpeed graph
With support for the QMP combo phy to react to USB Type-C switch events,
introduce it as the next hop for the SuperSpeed lanes of the two USB
Type-C connectors, and connect the output of the DisplayPort controller
to the QMP combo phy.
This allows the TCPM to perform orientation switching of both USB and
DisplayPort signals.
Tested-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450 Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230515032743.400170-8-quic_bjorande@quicinc.com
projects / thirdparty / kernel / linux.git / log
