- 14 Jun, 2023 8 commits
-
-
Stephan Gerhold authored
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 b0a8f16a ("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
-
Stephan Gerhold authored
Add the same comment to msm8939-pm8916.dtsi that was added for the MSM8916 variant in commit f1932649 ("arm64: dts: qcom: msm8916-pm8916: Clarify purpose"). Signed-off-by:
-
Stephan Gerhold authored
The regulator constraints for the MSM8939 devices 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. Apply the same change as for MSM8916 in commit 35575082 ("arm64: dts: qcom: msm8916: Fix regulator constraints") and make the voltages match the actual "specified range" in the PM8916 Device Specification which is enforced by the RPM firmware. Signed-off-by:
-
Stephan Gerhold authored
The vendor kernel from Sony does not have regulator-always-on for pm8916_l6, so we should be able to disable it when setting up the display properly. Since sony-tulip does not have display set up currently it should be fine to let the regulator disable until then. Signed-off-by:
-
Stephan Gerhold authored
msm8939-sony-xperia-kanuti-tulip.dts has several regulator voltages that do not quite seem to match what is used in the vendor kernel. In particular: - l10 is fixed at 2.8V [1, 2] - l11/l12 are 2.95V max [1] [1]: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/boot/dts/qcom/msm8939-regulator.dtsi [2]: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/boot/dts/qcom/msm8939-kanuti_tulip.dtsi#L671C1-L673 Fixes: f1134f73 ("arm64: dts: qcom: Add msm8939 Sony Xperia M4 Aqua") Signed-off-by:
-
Stephan Gerhold authored
Update for recent changes to msm8916.dtsi in commit a5cf21b1 ("arm64: dts: qcom: msm8916: Disable audio codecs by default") and make lpass_codec disabled by default for devices that are not using the audio codec functionality inside MSM8939. Signed-off-by:
-
Stephan Gerhold authored
Update for recent changes to pm8916.dtsi in commit 38218822 ("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:
-
Konrad Dybcio authored
Enable the PMIC GPIO- and RESIN-connected buttons on the board. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
- 13 Jun, 2023 32 commits
-
-
Stephan Gerhold authored
MSM8916 and MSM8939 are pin-compatible and should have exactly the same pinctrl definitions. Still, having pinctrl separated to a -pins.dtsi is not typical anymore for Qualcomm platforms upstream. Since Bjorn specifically requested having the MSM8939 pinctrl inside msm8939.dtsi lets move the MSM8916 definitions to msm8916.dtsi as well to have a consistent location. While at it sort the nodes and drop unnecessary empty lines. Note that in almost all cases changes to MSM8916 pinctrl should also be applied to MSM8939 pinctrl (and vice versa). Right now they are back in sync again and completely identical. Signed-off-by:
-
Stephan Gerhold authored
All the pinctrl now uses consistent _default/_sleep suffix so rename the WCNSS pinctrl to be named consistently. Signed-off-by:
-
Stephan Gerhold authored
The audio pinctrl in MSM8916/MSM8939 is very similar but still has subtle differences, e.g. &cdc_pdm_lines_act on MSM8916 vs &cdc_pdm_lines_default on MSM8939. Make this consistent and use the chance to cleanup all of the audio pinctrl: Drop unneeded outer nodes and replace the names taken over from the vendor kernel with more clear ones that are similar to the actual pinctrl function. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Stephan Gerhold authored
GPIO116 is not connected (NC) on DB410c so there is no need to route MCLK there. The MSM8916 digital codec receives the MCLK internally without leaving the SoC through a GPIO. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Stephan Gerhold authored
MSM8939 has the SDC pinctrl consolidated in two &sdcN_default and &sdcN_sleep states, while MSM8916 has all pins separated. Make this consistent by consolidating them for MSM8916 well. Use this as a chance to define default pinctrl in the SoC.dtsi and only let boards that add additional definitions (such as cd-gpios) override it. For MSM8939 just make the label consistent with the other pinctrl definitions (they do not have a _state suffix). Signed-off-by:
-
Stephan Gerhold authored
The current SD card detect pinctrl setup configures bias-pull-up for the "default" (active) case and bias-disable for the "sleep" case. Before commit b5c833b7 ("mmc: sdhci-msm: Set IO pins in low power state during suspend") the pull up was permanently active. Since then it is only active when a valid SD card is inserted. This does not really make sense: For an active-low CD, the pull up is needed to pull the GPIO high when the card is not inserted. When the card gets inserted CD is shorted to ground (low). This means right now the pull-up is removed exactly when it is needed to detect the next card insertion. Generally, applying different bias for CD does not really make sense. It should always stay the same so card removals and insertions can be detected properly. The reason why card detection still works fine in practice is that most boards seem to have external pull up on the CD pin. However, this means that there is no need to configure an internal pull-up at all and we can keep bias-disable permanently. There are also some boards with different CD polarity (acer-a1-724) and with different GPIO number (huawei-g7). All in all this makes it obvious that the CD pin is board-specific and the pinctrl for it should be defined in the board DT. Move it to the boards that need it and use bias-disable permanently for the boards that seem to have external pull-up. The vendor device tree for msm8939-sony-xperia-kanuti-tulip suggests that it needs the internal pull-up permanently [1] so it gets bias-pull-up to be sure. [1]: https://github.com/sonyxperiadev/kernel/blob/57b5050e340f40a88e1ddb8d16fd9adb44418923/arch/arm/boot/dts/qcom/msm8939-kanuti_tulip.dtsi#L634-L636Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and HDMI nodes stay apart, because labels for HDMI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change HDMI node labels from hdmi_* to mdss_hdmi_*. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
Currently in board files MDSS and DSI nodes stay apart, because labels for DSI nodes do not have the mdss_ prefix. It was found that grouping all display-related notes is more useful. To keep all display-related nodes close in the board files, change DSI node labels from dsi_* to mdss_dsi_*. Signed-off-by:
-
Dmitry Baryshkov authored
The MDP/DPU device is not disabled by default since the commit 0c25dad9 ("arm64: dts: qcom: sm8250: Don't disable MDP explicitly"), so there is not point in enabling it in the board DTS file. Signed-off-by:
-
Dmitry Baryshkov authored
The MDP/DPU device is not disabled by default, so there is not point in enabling it in the board DTS file. Signed-off-by:
-
Dmitry Baryshkov authored
The MDP/DPU device is not disabled by default, so there is not point in enabling it in the board DTS file. Signed-off-by:
-
Dmitry Baryshkov authored
MDSS and all its subdevices are useless without DPU/MDP, so disabling MDP doesn't make any sense. Remove explicit disabling of the DPU device. Signed-off-by:
-
Poovendhan Selvaraj authored
Add the initial device tree support for the Reference Design Platform (RDP) 454 based on IPQ9574 family of SoCs. This patch adds support for Console UART, SPI NOR and SMPA1 regulator node. Signed-off-by:
Poovendhan Selvaraj <quic_poovendh@quicinc.com> Signed-off-by:
-
Poovendhan Selvaraj authored
Document AL02-C9 (Reference Design Platform 454) board based on IPQ9574 family of SoCs. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Konrad Dybcio authored
Add GPUCC and Adreno SMMU nodes in preparation for adding the GPU itself. Signed-off-by:
-
Abel Vesa authored
The USB HC node is missing the interconnect paths, so add them. Fixes: 7f7e5c1b ("arm64: dts: qcom: sm8550: Add USB PHYs and controller nodes") Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
-
Komal Bajaj authored
Add sdhci node for emmc in qdu1000-idp. Reviewed-by:
Komal Bajaj <quic_kbajaj@quicinc.com> Signed-off-by:
-
Komal Bajaj authored
Add sdhc node for eMMC on QDU1000 and QRU1000 SoCs. Also add required pins for SDHCI, so that the interface can work reliably. Reviewed-by:
-
Abel Vesa authored
The USB HC node is missing the interconnect paths, so add them. Signed-off-by:
-
Abel Vesa authored
The USB HCs nodes are missing the interconnect paths, so add them. Signed-off-by:
-
Abel Vesa authored
The USB HCs nodes are missing the interconnect paths, so add them. Signed-off-by:
-
Abel Vesa authored
Use two interconnect cells in order to optionally support a path tag. Signed-off-by:
-
Abel Vesa authored
The USB HCs nodes are missing the interconnect paths, so add them. Signed-off-by:
-
Abel Vesa authored
Use two interconnect cells in order to optionally support a path tag. Signed-off-by:
-
Marijn Suijten authored
The framebuffer configuration for edo pdx203, written in edo dtsi (which is overwritten in pdx206 dts for its smaller panel) has to use a 1096x2560 configuration as this is what the panel (and framebuffer area) has been initialized to. Downstream userspace also has access to (and uses) this 2.5k mode by default, and only switches the panel to 4k when requested. This is similar to commit be8de06d ("arm64: dts: qcom: sm8150-kumano: Panel framebuffer is 2.5k instead of 4k") which fixed the same for the previous generation Sony platform. Fixes: 69cdb97e ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)") Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
-
