aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64/boot/dts/qcom
AgeCommit message (Collapse)AuthorFilesLines
2023-07-31arm64: dts: qcom: sc7180: Fix DSI0_PHY reg-namesKonrad Dybcio1-2/+2
Commit 2b616f86d51b ("arm64: dts: qcom: sc7180: rename labels for DSI nodes") broke reg-names, possibly with search-and-replace. Fix it. Fixes: 2b616f86d51b ("arm64: dts: qcom: sc7180: rename labels for DSI nodes") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230627-topic-more_bindings-v1-1-6b4b6cd081e5@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-13arm64: dts: qcom: sa8775p-ride: Update L4C parametersNaveen Kumar Goud Arepalli1-2/+2
L4c is the supply for UFS vccq, As per UFS spec range of vccq is 1.14V to 1.26V, There are stability issues when operating at marginal voltage. Hence configure the min and max vccq voltages to 1.2V. Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230711105915.30581-1-quic_narepall@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-09arm64: dts: qcom: qrb5165-rb5: fix thermal zone conflictDmitry Baryshkov1-1/+1
The commit 3a786086c6f8 ("arm64: dts: qcom: Add missing "-thermal" suffix for thermal zones") renamed the thermal zone in the pm8150l.dtsi file to comply with the schema. However this resulted in a clash with the RB5 board file, which already contained the pm8150l-thermal zone for the on-board sensor. This resulted in the board file definition overriding the thermal zone defined in the PMIC include file (and thus the on-die PMIC temp alarm was not probing at all). Rename the thermal zone in qcom/qrb5165-rb5.dts to remove this override. Fixes: 3a786086c6f8 ("arm64: dts: qcom: Add missing "-thermal" suffix for thermal zones") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230613131224.666668-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-09arm64: dts: qcom: sm8350: fix BAM DMA crash and rebootKrzysztof Kozlowski1-0/+4
SM8350 HDK and MTP boards were silently dying and rebooting during BAM DMA probe, probably during reading BAM_REVISION register: [ 1.574304] vreg_bob: Setting 3008000-3960000uV [ 1.576918] bam-dFormat: Log Type - Time(microsec) - Message - Optional Info Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.0-00637.1-LAHAINA-1 S - IMAGE_VARIANT_STRING=SocLahainaLAA S - OEM_IMAGE_VERSION_STRING=crm-ubuntu77 S - Boot Interface: UFS It seems that BAM DMA is not yet operational, thus mark it as failed and disable also QCE because it won't work without BAM DMA. Fixes: f1040a7fe8f0 ("arm64: dts: qcom: sm8350: Add Crypto Engine support") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-09arm64: dts: qcom: sc8180x: Fix OSM L3 compatibleKrzysztof Kozlowski1-1/+1
Since commit c70edc067739 ("dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles") OSM L3 compatible should have generic fallback: sc8180x-primus.dtb: interconnect@18321000: compatible: 'oneOf' conditional failed, one must be fixed: Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230617204118.61959-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-09arm64: dts: qcom: sm8250: Fix EPSS L3 interconnect cellsKrzysztof Kozlowski1-9/+9
Qualcomm EPSS L3 Interconnect does not take path (third) argument. This was introduced by commit b5a12438325b ("arm64: dts: qcom: sm8250: Use 2 interconnect cells") which probably wanted to use 2 cells only for RPMh interconnects. sm8250-hdk.dtb: interconnect@18590000: #interconnect-cells:0:0: 1 was expected Fixes: b5a12438325b ("arm64: dts: qcom: sm8250: Use 2 interconnect cells") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230617204118.61959-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-07-09arm64: dts: qcom: sm8150: Fix OSM L3 interconnect cellsKrzysztof Kozlowski1-9/+9
Qualcomm Operating State Manager (OSM) L3 Interconnect does not take path (third) argument. This was introduced by commit 97c289026c62 ("arm64: dts: qcom: sm8150: Use 2 interconnect cells") which probably wanted to use 2 cells only for RPMh interconnects. sm8150-microsoft-surface-duo.dtb: interconnect@18321000: #interconnect-cells:0:0: 1 was expected Fixes: 97c289026c62 ("arm64: dts: qcom: sm8150: Use 2 interconnect cells") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230617204118.61959-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-06-29Merge tag 'soc-dt-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds140-3438/+19482
Pull ARM SoC devicetree updates from Arnd Bergmann: "The biggest change this time is for the 32-bit devicetree files, which are all moved to a new location, using separate subdirectories for each SoC vendor, following the same scheme that is used on arm64, mips and riscv. This has been discussed for many years, but so far we never did this as there was a plan to move the files out of the kernel entirely, which has never happened. The impact of this will be that all external patches no longer apply, and anything depending on the location of the dtb files in the build directory will have to change. The installed files after 'make dtbs_install' keep the current location. There are six added SoCs here that are largely variants of previously added chips. Two other chips are added in a separate branch along with their device drivers. - The Samsung Exynos 4212 makes its return after the Samsung Galaxy Express phone is addded at last. The SoC support was originally added in 2012 but removed again in 2017 as it was unused at the time. - Amlogic C3 is a Cortex-A35 based smart IP camera chip - Qualcomm MSM8939 (Snapdragon 615) is a more featureful variant of the still common MSM8916 (Snapdragon 410) phone chip that has been supported for a long time. - Qualcomm SC8180x (Snapdragon 8cx) is one of their earlier high-end laptop chips, used in the Lenovo Flex 5G, which is added along with the reference board. - Qualcomm SDX75 is the latest generation modem chip that is used as a peripherial in phones but can also run a standalone Linux. Unlike the prior 32-bit SDX65 and SDX55, this now has a 64-bit Cortex-A55. - Alibaba T-Head TH1520 is a quad-core RISC-V chip based on the Xuantie C910 core, a step up from all previously added rv64 chips. All of the above come with reference board implementations, those included there are 39 new board files, but only five more 32-bit this time, probably a new low: - Marantec Maveo board based on dhcor imx6ull module - Endian 4i Edge 200, based on the armv5 Marvell Kirkwood chip - Epson Moverio BT-200 AR glasses based on TI OMAP4 - PHYTEC STM32MP1-3 Dev board based on STM32MP15 PHYTEC SOM - ICnova ADB4006 board based on Allwinner A20 On the 64-bit side, there are also fewer addded machines than we had in the recent releases: - Three boards based on NXP i.MX8: Emtop SoM & Baseboard, NXP i.MX8MM EVKB board and i.MX8MP based Gateworks Venice gw7905-2x device. - NVIDIA IGX Orin and Jetson Orin Nano boards, both based on tegra234 - Qualcomm gains support for 6 reference boards on various members of their IPQ networking SoC series, as well as the Sony Xperia M4 Aqua phone, the Acer Aspire 1 laptop, and the Fxtec Pro1X board on top of the various reference platforms for their new chips. - Rockchips support for several newer boards: Indiedroid Nova (rk3588), Edgeble Neural Compute Module 6B (rk3588), FriendlyARM NanoPi R2C Plus (rk3328), Anbernic RG353PS (rk3566), Lunzn Fastrhino R66S/R68S (rk3568) - TI K3/AM625 based PHYTEC phyBOARD-Lyra-AM625 board and Toradex Verdin family with AM62 COM, carrier and dev boards Other changes to existing boards contain the usual minor improvements along with - continued updates to clean up dts files based on dtc warnings and binding checks, in particular cache properties and node names - support for devicetree overlays on at91, bcm283x - significant additions to existing SoC support on mediatek, qualcomm, ti k3 family, starfive jh71xx, NXP i.MX6 and i.MX8, ST STM32MP1 As usual, a lot more detail is available in the individual merge commits" * tag 'soc-dt-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (926 commits) ARM: mvebu: fix unit address on armada-390-db flash ARM: dts: Move .dts files to vendor sub-directories kbuild: Support flat DTBs install ARM: dts: Add .dts files missing from the build ARM: dts: allwinner: Use quoted #include ARM: dts: lan966x: kontron-d10: add PHY interrupts ARM: dts: lan966x: kontron-d10: fix SPI CS ARM: dts: lan966x: kontron-d10: fix board reset ARM: dts: at91: Enable device-tree overlay support for AT91 boards arm: dts: Enable device-tree overlay support for AT91 boards arm64: dts: exynos: Remove clock from Exynos850 pmu_system_controller ARM: dts: at91: use generic name for shutdown controller ARM: dts: BCM5301X: Add cells sizes to PCIe nodes dt-bindings: firmware: brcm,kona-smc: convert to YAML riscv: dts: sort makefile entries by directory riscv: defconfig: enable T-HEAD SoC MAINTAINERS: add entry for T-HEAD RISC-V SoC riscv: dts: thead: add sipeed Lichee Pi 4A board device tree riscv: dts: add initial T-HEAD TH1520 SoC device tree riscv: Add the T-HEAD SoC family Kconfig option ...
2023-06-22arm64: dts: qcom: sc7280: Mark SCM as dma-coherent for chrome devicesDouglas Anderson2-1/+6
Just like for sc7180 devices using the Chrome bootflow (AKA trogdor and IDP), sc7280 devices using the Chrome bootflow also need their firmware marked dma-coherent. On sc7280 this wasn't causing WiFi to fail to startup, since WiFi works differently there. However, on sc7280 devices we were still getting the message at bootup after commit 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"""): qcom_scm firmware:scm: Assign memory protection call failed -22 qcom_rmtfs_mem 9c900000.memory: assign memory failed qcom_rmtfs_mem: probe of 9c900000.memory failed with error -22 We should mark SCM properly just like we did for trogdor. Fixes: 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""") Fixes: 7a1f4e7f740d ("arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230616081440.v2.4.I21dc14a63327bf81c6bb58fe8ed91dbdc9849ee2@changeid Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-06-22arm64: dts: qcom: sc7180: Mark SCM as dma-coherent for trogdorDouglas Anderson1-0/+5
Trogdor devices use firmware backed by TF-A instead of Qualcomm's normal TZ. On TF-A we end up mapping memory as cacheable. Specifically, you can see in Trogdor's TF-A code [1] in qti_sip_mem_assign() that we call qti_mmap_add_dynamic_region() with MT_RO_DATA. This translates down to MT_MEMORY instead of MT_NON_CACHEABLE or MT_DEVICE. Apparently Qualcomm's normal TZ implementation maps the memory as non-cacheable. Let's add the "dma-coherent" attribute to the SCM for trogdor. Adding "dma-coherent" like this fixes WiFi on sc7180-trogdor devices. WiFi was broken as of commit 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"""). Specifically at bootup we'd get: qcom_scm firmware:scm: Assign memory protection call failed -22 qcom_rmtfs_mem 94600000.memory: assign memory failed qcom_rmtfs_mem: probe of 94600000.memory failed with error -22 From discussion on the mailing lists [2] and over IRC [3], it was determined that we should always have been tagging the SCM as dma-coherent on trogdor but that the old "invalidate" happened to make things work most of the time. Tagging it properly like this is a much more robust solution. [1] https://chromium.googlesource.com/chromiumos/third_party/arm-trusted-firmware/+/refs/heads/firmware-trogdor-13577.B/plat/qti/common/src/qti_syscall.c [2] https://lore.kernel.org/r/20230614165904.1.I279773c37e2c1ed8fbb622ca6d1397aea0023526@changeid [3] https://oftc.irclog.whitequark.org/linux-msm/2023-06-15 Fixes: 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""") Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230616081440.v2.3.Ic62daa649b47b656b313551d646c4de9a7da4bd4@changeid Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-06-22arm64: dts: qcom: sc7180: Mark SCM as dma-coherent for IDPDouglas Anderson2-1/+6
sc7180-idp is, for most intents and purposes, a trogdor device. Specifically, sc7180-idp is designed to run the same style of firmware as trogdor devices. This can be seen from the fact that IDP has the same "Reserved memory changes" in its device tree that trogdor has. Recently it was realized that we need to mark SCM as dma-coherent to match what trogdor's style of firmware (based on TF-A) does [1]. That means we need this dma-coherent tag on IDP as well. Without this, on newer versions of Linux, specifically those with commit 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"""), WiFi will fail to work. At bootup you'll see: qcom_scm firmware:scm: Assign memory protection call failed -22 qcom_rmtfs_mem 94600000.memory: assign memory failed qcom_rmtfs_mem: probe of 94600000.memory failed with error -22 [1] https://lore.kernel.org/r/20230615145253.1.Ic62daa649b47b656b313551d646c4de9a7da4bd4@changeid Fixes: 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""") Fixes: f5ab220d162c ("arm64: dts: qcom: sc7180: Add remoteproc enablers") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230616081440.v2.2.I3c17d546d553378aa8a0c68c3fe04bccea7cba17@changeid Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2023-06-14arm64: dts: qcom: sc8280xp: Enable GPU related nodesBjorn Andersson2-0/+28
Add memory reservation for the zap-shader and enable the Adreno SMMU, GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the Lenovo ThinkPad X13s. Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230614142204.2675653-3-quic_bjorande@quicinc.com
2023-06-14arm64: dts: qcom: sc8280xp: Add GPU related nodesBjorn Andersson2-0/+183
Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the SC8280XP. Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230614142204.2675653-2-quic_bjorande@quicinc.com
2023-06-14arm64: dts: qcom: msm8939-pm8916: Mark always-on regulatorsStephan Gerhold1-0/+5
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. The same changes was already made for MSM8916 in commit 8bbd35771f90 ("arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators"). Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-8-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939: Define regulator constraints next to usageStephan Gerhold3-216/+80
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@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
2023-06-14arm64: dts: qcom: msm8939-pm8916: Clarify purposeStephan Gerhold1-0/+8
Add the same comment to msm8939-pm8916.dtsi that was added for the MSM8916 variant in commit f193264986b5 ("arm64: dts: qcom: msm8916-pm8916: Clarify purpose"). Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-6-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939: Fix regulator constraintsStephan Gerhold2-12/+12
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 355750828c55 ("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 <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-5-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939-sony-tulip: Allow disabling pm8916_l6Stephan Gerhold1-1/+0
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 <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-4-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939-sony-tulip: Fix l10-l12 regulator voltagesStephan Gerhold1-4/+4
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: f1134f738fad ("arm64: dts: qcom: Add msm8939 Sony Xperia M4 Aqua") 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-3-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939: Disable lpass_codec by defaultStephan Gerhold2-0/+5
Update for recent changes to msm8916.dtsi in commit a5cf21b14666 ("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 <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-2-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: msm8939-pm8916: Add missing pm8916_codec suppliesStephan Gerhold1-0/+6
Update for recent changes to pm8916.dtsi in commit 38218822a72f ("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: 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-1-a3c3ac833567@gerhold.net
2023-06-14arm64: dts: qcom: qrb4210-rb2: Enable on-board buttonsKonrad Dybcio1-0/+37
Enable the PMIC GPIO- and RESIN-connected buttons on the board. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230613-topic-rb2_-v1-1-696cd7dbda28@linaro.org
2023-06-13arm64: dts: qcom: msm8916: Drop msm8916-pins.dtsiStephan Gerhold2-556/+479
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 <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-6-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: msm8916/39: Rename wcnss pinctrlStephan Gerhold3-4/+4
All the pinctrl now uses consistent _default/_sleep suffix so rename the WCNSS pinctrl to be named consistently. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-5-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: msm8916/39: Cleanup audio pinctrlStephan Gerhold5-147/+133
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 <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-4-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: apq8016-sbc: Drop unneeded MCLK pinctrlStephan Gerhold1-2/+2
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 <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-3-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: msm8916/39: Consolidate SDC pinctrlStephan Gerhold19-143/+72
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 <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-2-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: msm8916/39: Fix SD card detect pinctrlStephan Gerhold13-54/+93
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 b5c833b703cc ("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-L636 Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230529-msm8916-pinctrl-v1-1-11f540b51c93@gerhold.net
2023-06-13arm64: dts: qcom: msm8996: rename labels for HDMI nodesDmitry Baryshkov4-38/+38
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: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531011623.3808538-14-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sm8250: rename labels for DSI nodesDmitry Baryshkov4-133/+133
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 <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/20230531011623.3808538-13-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sdm845: rename labels for DSI nodesDmitry Baryshkov9-314/+314
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 <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/20230531011623.3808538-12-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sdm630: rename labels for DSI nodesDmitry Baryshkov3-30/+30
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 <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/20230531011623.3808538-11-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sc8180x: rename labels for DSI nodesDmitry Baryshkov1-12/+12
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 <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/20230531011623.3808538-10-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sc7280: rename labels for DSI nodesDmitry Baryshkov1-3/+3
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 <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/20230531011623.3808538-9-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sc7180: rename labels for DSI nodesDmitry Baryshkov10-109/+109
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 <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/20230531011623.3808538-8-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: msm8996: rename labels for DSI nodesDmitry Baryshkov5-62/+62
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 <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/20230531011623.3808538-7-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: msm8953: rename labels for DSI nodesDmitry Baryshkov1-20/+20
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 <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/20230531011623.3808538-6-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: qrb5165-rb5: remove useless enablement of mdss_mdpDmitry Baryshkov1-4/+0
The MDP/DPU device is not disabled by default since the commit 0c25dad9f2a7 ("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 <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/20230531011623.3808538-5-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sm8450-hdk: remove useless enablement of mdss_mdpDmitry Baryshkov1-4/+0
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 <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/20230531011623.3808538-4-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sm8350-hdk: remove useless enablement of mdss_mdpDmitry Baryshkov1-4/+0
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 <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/20230531011623.3808538-3-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: sc7280: Don't disable MDP explicitlyDmitry Baryshkov2-6/+0
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: 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/20230531011623.3808538-2-dmitry.baryshkov@linaro.org
2023-06-13arm64: dts: qcom: ipq9574: add support for RDP454 variantPoovendhan Selvaraj2-0/+81
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: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531032648.23816-3-quic_poovendh@quicinc.com
2023-06-13arm64: dts: qcom: sm6375: Add GPUCC and Adreno SMMUKonrad Dybcio1-0/+37
Add GPUCC and Adreno SMMU nodes in preparation for adding the GPU itself. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531-topic-sm6375_gpusmmu-v1-2-860943894c71@linaro.org
2023-06-13arm64: dts: qcom: sm8550: Add missing interconnect path to USB HCAbel Vesa1-0/+4
The USB HC node is missing the interconnect paths, so add them. Fixes: 7f7e5c1b037f ("arm64: dts: qcom: sm8550: Add USB PHYs and controller nodes") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230601103817.4066446-1-abel.vesa@linaro.org
2023-06-13arm64: dts: qcom: qdu1000-idp: add SDHCI for emmcKomal Bajaj1-0/+23
Add sdhci node for emmc in qdu1000-idp. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230601111128.19562-4-quic_kbajaj@quicinc.com
2023-06-13arm64: dts: qcom: qdu1000: Add SDHCI nodeKomal Bajaj1-0/+97
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: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230601111128.19562-3-quic_kbajaj@quicinc.com
2023-06-13arm64: dts: qcom: sm8450: Add missing interconnect paths to USB HCAbel Vesa1-0/+4
The USB HC node is missing the interconnect paths, so add them. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230602062016.1883171-6-abel.vesa@linaro.org
2023-06-13arm64: dts: qcom: sm8350: Add missing interconnect paths to USB HCsAbel Vesa1-0/+8
The USB HCs nodes are missing the interconnect paths, so add them. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230602062016.1883171-5-abel.vesa@linaro.org
2023-06-13arm64: dts: qcom: sm8250: Add missing interconnect paths to USB HCsAbel Vesa1-0/+8
The USB HCs nodes are missing the interconnect paths, so add them. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230602062016.1883171-4-abel.vesa@linaro.org
2023-06-13arm64: dts: qcom: sm8250: Use 2 interconnect cellsAbel Vesa1-36/+36
Use two interconnect cells in order to optionally support a path tag. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230602062016.1883171-3-abel.vesa@linaro.org