summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-14arm64: dts: qcom: sm8150: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-9-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sc7180: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-8-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: qdu1000: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-7-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sm8250: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-6-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sm8550: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-5-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sm6350: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-4-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sc7280: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-3-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: sdm845: Supply clock from cpufreq node to CPUsManivannan Sadhasivam
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks to the CPU cores. But this relationship is not represented in DTS so far. So let's make cpufreq node as the clock provider and CPU nodes as the consumers. The clock index for each CPU node is based on the frequency domain index. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230215070400.5901-2-manivannan.sadhasivam@linaro.org
2023-03-14arm64: dts: qcom: add initial support for qcom sa8775p-rideBartosz Golaszewski
This adds basic support for the Qualcomm sa8775p platform and the reference board: sa8775p-ride. The dt files describe the basics of the SoC and enable booting to shell. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230214092713.211054-3-brgl@bgdev.pl
2023-03-14arm64: dts: qcom: pm8998: Add a specific compatible for coincell chgKonrad Dybcio
Add a PM8998-specific compatible to the coincell charger and keep the PM8941 one as fallback. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230214090849.2186370-3-konrad.dybcio@linaro.org
2023-03-14arm64: dts: qcom: msm8998: Fix stm-stimulus-base reg nameKonrad Dybcio
The name stm-data-base comes from ancient (msm-3.10 or older) downstream kernels. Upstream uses stm-stimulus-base instead. Fix it. Fixes: 783abfa2249a ("arm64: dts: qcom: msm8998: Add Coresight support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213210331.2106877-1-konrad.dybcio@linaro.org
2023-03-14arm64: dts: qcom: sm6375: Add RMTFSKonrad Dybcio
Add a node for RMTFS on SM6375. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213175928.1979637-1-konrad.dybcio@linaro.org
2023-03-14arm64: dts: qcom: sm8550-qrd: add QRD8550Krzysztof Kozlowski
Add a minimal DTS for the new QRD8550 board - a mobile-like development board with SM8550. Serial, UFS and USB should be working. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230210163844.765074-2-krzysztof.kozlowski@linaro.org
2023-03-14arm64: dts: qcom: sm8550-mtp: Add eUSB2 repeater nodeAbel Vesa
Add the PMIC eUSB2 repeater node and add the usb-repeater property to the eUSB2 PHY to allow it to be controlled by the PHY driver. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208190200.2966723-8-abel.vesa@linaro.org
2023-03-14arm64: dts: qcom: pm8550b: Add eUSB2 repeater nodeNeil Armstrong
Add nodes for the eUSB2 repeater found on the pm8550b SPMI PMIC. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208190200.2966723-7-abel.vesa@linaro.org
2023-03-14arm64: dts: qcom: sm8550: Fix PCIe PHYs and controllers nodesAbel Vesa
First, move the pinctrl related propeties out from SoC dtsi and into the board dts and add blank lines before status properties in the PHY nodes to be consistent with the rest of the nodes. Then drop the pipe clock from the controller nodes. Rename the aggre0 and aggre1 clocks to more generic noc_aggr, and then the cnoc_pcie_sf_axi to cnoc_sf_axi. Add the cpu-pcie interconnects to both controller nodes. Rename the pcie1 second reset to link_down and drop the unnecessary enable-gpios. Switch the aux clock to GCC_PCIE_1_PHY_AUX_CLK for the pcie1 PHY and drop the aux_phy from clock-names. Also rename the nocsr reset to phy_nocsr. With this changes we are now in line with the SC8280XP bindings. Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208180020.2761766-12-abel.vesa@linaro.org
2023-03-13dt-bindings: clock: Add Qcom SM6115 GPUCCKonrad Dybcio
Add device tree bindings for graphics clock controller for Qualcomm Technology Inc's SM6115 SoCs. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208091340.124641-10-konrad.dybcio@linaro.org
2023-03-13dt-bindings: clock: Add Qcom SM6375 GPUCCKonrad Dybcio
Add device tree bindings for graphics clock controller for Qualcomm Technology Inc's SM6375 SoCs. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208091340.124641-8-konrad.dybcio@linaro.org
2023-03-13dt-bindings: clock: Add Qcom SM6125 GPUCCKonrad Dybcio
Add device tree bindings for graphics clock controller for Qualcomm Technology Inc's SM6125 SoCs. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208091340.124641-6-konrad.dybcio@linaro.org
2023-03-13arm64: dts: qcom: sc8280xp-x13s: enable rtcJohan Hovold
The Lenovo X13s firmware does not implement the UEFI time runtime services so the RTC in the PM8280K PMIC needs to be accessed directly. To complicate things further, the RTC control and time registers are read-only on this platform so an offset must be stored in some other machine-specific non-volatile memory which an RTC driver can take into account when reading or updating the time. The UEFI firmware (and Windows) use a UEFI variable for this: 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo but the offset can only be accessed via the Qualcomm UEFI Secure Application residing in the TEE as the firmware does not implement the variable runtime services either. While it is possible to access this UEFI variable from Linux on the X13s, this requires using a fairly complex and reverse-engineered firmware interface. As the only benefit of doing so is to make sure that the UEFI (Windows) and Linux time never gets out of sync, it seems preferable to use the PMIC scratch registers for storing an offset instead. This also avoids flash wear in case of RTC drift, etc. So instead of using the UEFI RTC offset, reserve four bytes in one of the PMIC SDAM scratch-register blocks to hold the RTC offset. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202155448.6715-23-johan+linaro@kernel.org
2023-03-13arm64: dts: qcom: sc8280xp-crd: enable rtcJohan Hovold
The SC8280XP CRD firmware does not implement the UEFI time runtime services so the RTC in the PM8280K PMIC needs to be accessed directly. To complicate things further, the RTC control and time registers are read-only on this platform so an offset must be stored in some other machine-specific non-volatile memory which an RTC driver can take into account when reading or updating the time. The UEFI firmware (and Windows) use a UEFI variable for this: 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo but the offset can only be accessed via the Qualcomm UEFI Secure Application residing in the TEE as the firmware does not implement the variable runtime services either. While it is possible to access this UEFI variable from Linux on the CRD, this requires using a fairly complex and reverse-engineered firmware interface. As the only benefit of doing so is to make sure that the UEFI (Windows) and Linux time never gets out of sync, it seems preferable to use the PMIC scratch registers for storing an offset instead. This also avoids flash wear in case of RTC drift, etc. Also note that setting variables using this interface does not work on at least one CRD for reasons not yet known. So instead of using the UEFI RTC offset, reserve four bytes in one of the PMIC SDAM scratch-register blocks to hold the RTC offset. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202155448.6715-22-johan+linaro@kernel.org
2023-03-13arm64: dts: qcom: sc8280xp-pmics: add pmk8280 sdam nvramJohan Hovold
Add one of the PMK8280 SDAM blocks which can be used to store an RTC offset. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202155448.6715-21-johan+linaro@kernel.org
2023-03-13arm64: dts: qcom: sc8280xp-pmics: add pmk8280 rtcJohan Hovold
The PMK8280 has an RTC which can also be used as a wakeup source. Note that the RTC can not be disabled and updating the time is not permitted either. Instead an offset can be stored in some other machine- specific non-volatile memory which a driver can take into account. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202155448.6715-20-johan+linaro@kernel.org
2023-03-13arm64: dts: qcom: sdm670: add opps for peripheralsRichard Acayan
The interconnects are now in place. Add Operating Performance Points for them to allow the kernel to properly manage them. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230201010020.84586-3-mailingradian@gmail.com
2023-03-13arm64: dts: qcom: sm6115: Add remoteproc nodesBhupesh Sharma
Add the adsp, cdsp and modem remoteproc nodes to sm6115. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> [bjorn: Extended regs to match #address/size-cells to 2] Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230128054256.2100501-1-bhupesh.sharma@linaro.org
2023-03-13arm64: dts: qcom: sa8155p-adp: enable the GNSS high-speed UARTBartosz Golaszewski
Enable the high-speed UART port that's connected to the GNSS controller on the board. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230309143551.200694-3-brgl@bgdev.pl
2023-03-13arm64: dts: sm8150: add the QUPv3 high-speed UART nodeBartosz Golaszewski
Add the high-speed UART node to the dtsi for sm8150. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230309143551.200694-2-brgl@bgdev.pl
2023-03-09arm64: dts: qcom: sm8550: Mark UFS controller as cache coherentManivannan Sadhasivam
The UFS controller on SM8550 supports cache coherency, hence add the "dma-coherent" property to mark it as such. Fixes: 35cf1aaab169 ("arm64: dts: qcom: sm8550: Add UFS host controller and phy nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230308054630.7202-1-manivannan.sadhasivam@linaro.org
2023-03-09arm64: dts: qcom: sa8540p-ride: correct name of remoteproc_nsp0 firmwareBrian Masney
The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and correct the name to match what's in Qualcomm's deliverable. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307232340.2370476-1-bmasney@redhat.com
2023-03-09arm64: dts: qcom: sm8450: Mark UFS controller as cache coherentManivannan Sadhasivam
The UFS controller on SM8450 supports cache coherency, hence add the "dma-coherent" property to mark it as such. Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307153201.180626-2-manivannan.sadhasivam@linaro.org
2023-03-09arm64: dts: qcom: sm8350: Mark UFS controller as cache coherentManivannan Sadhasivam
The UFS controller on SM8350 supports cache coherency, hence add the "dma-coherent" property to mark it as such. Fixes: 59c7cf814783 ("arm64: dts: qcom: sm8350: Add UFS nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307153201.180626-1-manivannan.sadhasivam@linaro.org
2023-03-09arm64: dts: qcom: sm8550: fix LPASS pinctrl slew base addressKrzysztof Kozlowski
The second LPASS pin controller IO address is supposed to be the MCC range which contains the slew rate registers. The Linux driver then accesses slew rate register with hard-coded offset (0xa000). However the DTS contained the address of slew rate register as the second IO address, thus any reads were effectively pass the memory space and lead to "Internal error: synchronous external aborts" when applying pin configuration. Fixes: 6de7f9c34358 ("arm64: dts: qcom: sm8550: add GPR and LPASS pin controller") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230302154724.856062-1-krzysztof.kozlowski@linaro.org
2023-03-09arm64: dts: qcom: sc8280xp-x13s: fix va dmic dai links and routingSrinivas Kandagatla
VA dmics 0, 1, 2 micbias on X13s are connected to WCD MICBIAS1, WCD MICBIAS1 and WCD MICBIAS3 respectively. Reflect this in dt to get dmics working. Also fix dmics to go via VA Macro instead of TX macro to fix device switching. Fixes: 8c1ea87e80b4 ("arm64: dts: qcom: sc8280xp-x13s: Add soundcard support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230302115741.7726-5-srinivas.kandagatla@linaro.org
2023-03-09arm64: dts: qcom: sc8280xp-x13s: fix dmic sample rateSrinivas Kandagatla
The version of dmic that is on X13s panel supports clock frequency of range 1 Mhz to 4.8 MHz for normal operation. So correct the existing node to reflect this. Fixes: 8c1ea87e80b4 ("arm64: dts: qcom: sc8280xp-x13s: Add soundcard support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230302115741.7726-4-srinivas.kandagatla@linaro.org
2023-03-09arm64: dts: qcom: sc8280xp: fix lpass tx macro clocksSrinivas Kandagatla
Tx macro soundwire clock is for some reason is incorrectly assigned to va macro, fix this and use tx macro clock instead. Fixes: 1749a8ae49a3 ("arm64: dts: qcom: sc8280xp: add SoundWire and LPASS") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230302115741.7726-3-srinivas.kandagatla@linaro.org
2023-03-09arm64: dts: qcom: sc8280xp: fix rx frame shapping infoSrinivas Kandagatla
Some of the SoundWire frameshapping data seems incorrect, fix these values. Fixes: 1749a8ae49a3 ("arm64: dts: qcom: sc8280xp: add SoundWire and LPASS") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230302115741.7726-2-srinivas.kandagatla@linaro.org
2023-03-09arm64: dts: qcom: sm8450: correct WSA2 assigned clocksKrzysztof Kozlowski
The WSA2 assigned-clocks were copied from WSA, but the WSA2 uses its own. Fixes: 14341e76dbc7 ("arm64: dts: qcom: sm8450: add Soundwire and LPASS") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230308123129.232642-1-krzysztof.kozlowski@linaro.org
2023-03-06arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherentKrishna chaitanya chundru
If the controller is not marked as cache coherent, then kernel will try to ensure coherency during dma-ops and that may cause data corruption. So, mark the PCIe node as dma-coherent as the devices on PCIe bus are cache coherent. Cc: stable@vger.kernel.org Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related node") Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1677584952-17496-1-git-send-email-quic_krichai@quicinc.com
2023-03-06arm64: dts: qcom: msm8916-ufi: Fix sim card selection pinctrlYang Xiwen
The previous commit mistakenly introduced sim_ctrl_default as pinctrl, this is incorrect, the interface for sim card selection varies between different devices and should not be placed in the dtsi. This commit selects external SIM card slot for ufi001c as default. uf896 selects the correct SIM card slot automatically, thus does not need this pinctrl node. Fixes: faf69431464b ("arm64: dts: qcom: msm8916-thwc: Add initial device trees") Signed-off-by: Yang Xiwen <forbidden405@foxmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/tencent_7036BCA256055D05F8C49D86DF7F0E2D1A05@qq.com
2023-03-06arm64: dts: qcom: sm8250-xiaomi-elish: Correct venus firmware pathJianhua Lu
Missing vendor name for venus firmware path. Add it. Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Jianhua Lu <lujianhua000@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230221123633.25145-1-lujianhua000@gmail.com
2023-03-06arm64: dts: qcom: sm8550: Use correct CPU compatiblesKonrad Dybcio
Use the correct compatibles for the four kinds of CPU cores used on SM8550, based on the value of their MIDR_EL1 registers: CPU7: 0x411fd4e0 - CX3 r1p1 CPU5-6: 0x412fd470 - CA710 r?p? CPU3-4: 0x411fd4d0 - CA715 r?p? CPU0-2: 0x411fd461 - CA510 r?p? Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230216110803.3945747-2-konrad.dybcio@linaro.org
2023-03-06arm64: dts: qcom: sm8550: Add bias pull up value to tlmm i2c data clk statesAbel Vesa
The default bias pull up value for the tlmm i2c data clk states is 2.2kOhms. Add this value to make sure the driver factors in the i2c pull up bit when writing the config register. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230209074510.4153294-2-abel.vesa@linaro.org
2023-03-06arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSPKonrad Dybcio
This was omitted when first introducing the node. Fix it. Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230109135647.339224-5-konrad.dybcio@linaro.org
2023-03-06arm64: dts: qcom: sm6115: Un-enable SPI5 by defaultKonrad Dybcio
The commit mentioned in the fixes tag erroneously enabled SPI5 unconditionally. Undo it. Fixes: 25aab0b852d6 ("arm64: dts: qcom: sm6115: Add geni debug uart node for qup0") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230216124921.3985834-1-konrad.dybcio@linaro.org
2023-03-06arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodesManivannan Sadhasivam
For uniquely identifying the vadc channels, label property has to be used. The initial commit adding vadc support assumed that the driver will use the unit address along with the node name to identify the channels. But this assumption is now broken by, commit 701c875aded8 ("iio: adc: qcom-spmi-adc5: Fix the channel name") that stripped unit address from channel names. This results in probe failure of the vadc driver: [ 8.380370] iio iio:device0: tried to double register : in_temp_pmic-die-temp_input [ 8.380383] qcom-spmi-adc5 c440000.spmi:pmic@0:adc@3100: Failed to register sysfs interfaces [ 8.380386] qcom-spmi-adc5: probe of c440000.spmi:pmic@0:adc@3100 failed with error -16 Hence, let's get rid of the assumption about drivers and rely on label property to uniquely identify the channels. The labels are derived from the schematics for each PMIC. For internal adc channels such as die and xo, the PMIC names are used as a prefix. Fixes: 7c0151347401 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} ADC_TM5 channels") Fixes: 9d41cd17394a ("arm64: dts: qcom: sc8280xp-x13s: Add PMR735A VADC channel") Fixes: 3375151a7185 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} VADC channels") Fixes: 9a6b3042c533 ("arm64: dts: qcom: sc8280xp-x13s: Add PMK8280 VADC channels") Reported-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230211052415.14581-1-manivannan.sadhasivam@linaro.org
2023-03-06arm64: dts: qcom: sm8150: Fix the iommu mask used for PCIe controllersManivannan Sadhasivam
The iommu mask should be 0x3f as per Qualcomm internal documentation. Without the correct mask, the PCIe transactions from the endpoint will result in SMMU faults. Hence, fix it! Cc: stable@vger.kernel.org # 5.19 Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230224080045.6577-1-manivannan.sadhasivam@linaro.org
2023-03-05Linux 6.3-rc1v6.3-rc1Linus Torvalds
2023-03-05cpumask: re-introduce constant-sized cpumask optimizationsLinus Torvalds
Commit aa47a7c215e7 ("lib/cpumask: deprecate nr_cpumask_bits") resulted in the cpumask operations potentially becoming hugely less efficient, because suddenly the cpumask was always considered to be variable-sized. The optimization was then later added back in a limited form by commit 6f9c07be9d02 ("lib/cpumask: add FORCE_NR_CPUS config option"), but that FORCE_NR_CPUS option is not useful in a generic kernel and more of a special case for embedded situations with fixed hardware. Instead, just re-introduce the optimization, with some changes. Instead of depending on CPUMASK_OFFSTACK being false, and then always using the full constant cpumask width, this introduces three different cpumask "sizes": - the exact size (nr_cpumask_bits) remains identical to nr_cpu_ids. This is used for situations where we should use the exact size. - the "small" size (small_cpumask_bits) is the NR_CPUS constant if it fits in a single word and the bitmap operations thus end up able to trigger the "small_const_nbits()" optimizations. This is used for the operations that have optimized single-word cases that get inlined, notably the bit find and scanning functions. - the "large" size (large_cpumask_bits) is the NR_CPUS constant if it is an sufficiently small constant that makes simple "copy" and "clear" operations more efficient. This is arbitrarily set at four words or less. As a an example of this situation, without this fixed size optimization, cpumask_clear() will generate code like movl nr_cpu_ids(%rip), %edx addq $63, %rdx shrq $3, %rdx andl $-8, %edx callq memset@PLT on x86-64, because it would calculate the "exact" number of longwords that need to be cleared. In contrast, with this patch, using a MAX_CPU of 64 (which is quite a reasonable value to use), the above becomes a single movq $0,cpumask instruction instead, because instead of caring to figure out exactly how many CPU's the system has, it just knows that the cpumask will be a single word and can just clear it all. Note that this does end up tightening the rules a bit from the original version in another way: operations that set bits in the cpumask are now limited to the actual nr_cpu_ids limit, whereas we used to do the nr_cpumask_bits thing almost everywhere in the cpumask code. But if you just clear bits, or scan for bits, we can use the simpler compile-time constants. In the process, remove 'cpumask_complement()' and 'for_each_cpu_not()' which were not useful, and which fundamentally have to be limited to 'nr_cpu_ids'. Better remove them now than have somebody introduce use of them later. Of course, on x86-64 with MAXSMP there is no sane small compile-time constant for the cpumask sizes, and we end up using the actual CPU bits, and will generate the above kind of horrors regardless. Please don't use MAXSMP unless you really expect to have machines with thousands of cores. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-03-05Merge tag 'v6.3-p2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in the caam driver" * tag 'v6.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - Fix edesc/iv ordering mixup
2023-03-05Merge tag 'x86-urgent-2023-03-05' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 updates from Thomas Gleixner: "A small set of updates for x86: - Return -EIO instead of success when the certificate buffer for SEV guests is not large enough - Allow STIPB to be enabled with legacy IBSR. Legacy IBRS is cleared on return to userspace for performance reasons, but the leaves user space vulnerable to cross-thread attacks which STIBP prevents. Update the documentation accordingly" * tag 'x86-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: virt/sev-guest: Return -EIO if certificate buffer is not large enough Documentation/hw-vuln: Document the interaction between IBRS and STIBP x86/speculation: Allow enabling STIBP with legacy IBRS