- 15 Mar, 2023 39 commits
-
-
Bartosz Golaszewski authored
There's a typo in the @<address> part of the uart9 label. Fix it. Fixes: 10d900a8 ("arm64: dts: sm8150: add the QUPv3 high-speed UART node") Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230315202751.1518543-1-brgl@bgdev.pl
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. On SM6350, there is only one LLCC bank available. So let's just pass that as "llcc0_base". Reported-by:
Parikshit Pareek <quic_ppareek@quicinc.com> Tested-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. While at it, let's also fix the size of the llcc_broadcast_base to cover the whole region. Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. On SC7180, there is only one LLCC bank available. So let's just pass that as "llcc0_base". Reported-by:
-
Manivannan Sadhasivam authored
The LLCC block has several banks each with a different base address and holes in between. So it is not a correct approach to cover these banks with a single offset/size. Instead, the individual bank's base address needs to be specified in devicetree with the exact size. On SDM845, the size of the LLCC bank 0 needs to be reduced to 0x4500 as there are LLCC BWMON registers located after this range. Reported-by:
-
Konrad Dybcio authored
Add missing dwc3 quirks from msm-3.18. Unfortunately, none of them make `dwc3-qcom 6af8800.usb: HS-PHY not in L2` go away. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Mukesh Ojha authored
Add a simple-mfd representing IMEM on SM8450 and define the PIL relocation info region, so that post mortem tools will be able to locate the loaded remoteprocs. Signed-off-by:
Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by:
-
Bartosz Golaszewski authored
Add a node for the cpufreq engine and specify the frequency domains for all CPUs. Signed-off-by:
-
Krzysztof Kozlowski authored
Correct indentation. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Krzysztof Kozlowski authored
The WCD9335 audio codec on Slimbus is a property of a board, not SoC, thus it should not be present in MSM8996 DTSI. Keep it in specific boards, so it won't appear incomplete in the boards not having it. Signed-off-by:
-
Konrad Dybcio authored
Add the fallback Qualcomm SMMU500 compatible to the Adreno SMMU. Signed-off-by:
-
Konrad Dybcio authored
Add the fallback Qualcomm SMMU500 compatible to the Adreno SMMU. Signed-off-by:
-
Konrad Dybcio authored
Add the fallback Qualcomm SMMU500 compatible to the Adreno SMMU. Signed-off-by:
-
Konrad Dybcio authored
Add the fallback Qualcomm SMMU500 compatible to the Adreno SMMU. Signed-off-by:
-
Manivannan Sadhasivam authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Bartosz Golaszewski authored
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:
-
Konrad Dybcio authored
Add a PM8998-specific compatible to the coincell charger and keep the PM8941 one as fallback. Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
-
Konrad Dybcio authored
The name stm-data-base comes from ancient (msm-3.10 or older) downstream kernels. Upstream uses stm-stimulus-base instead. Fix it. Fixes: 783abfa2 ("arm64: dts: qcom: msm8998: Add Coresight support") Signed-off-by:
-
Konrad Dybcio authored
Add a node for RMTFS on SM6375. Signed-off-by:
-
Krzysztof Kozlowski authored
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:
Abel Vesa <abel.vesa@linaro.org> Signed-off-by:
-
Abel Vesa authored
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:
-
Neil Armstrong authored
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 authored
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: 7d1158c9 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Signed-off-by:
-
- 13 Mar, 2023 1 commit
-
-
Johan Hovold authored
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:
-
