Kathiravan T [Fri, 19 May 2023 13:38:44 +0000 (19:08 +0530)]
arm64: dts: qcom: ipq5332: add few more reserved memory region
In IPQ SoCs, bootloader will collect the system RAM contents upon crash for
the post morterm analysis. If we don't reserve the memory region used by
bootloader, obviously linux will consume it and upon next boot on crash,
bootloader will be loaded in the same region, which will lead to loose some
of the data, sometimes we may miss out critical information. So lets
reserve the region used by the bootloader.
Similarly SBL copies some data into the reserved region and it will be
used in the crash scenario. So reserve 1MB for SBL as well.
While at it, drop the size padding in the smem memory region.
Luca Weiss [Fri, 12 May 2023 13:58:26 +0000 (15:58 +0200)]
arm64: dts: qcom: sm7225-fairphone-fp4: Add Bluetooth
The device has a WCN3988 chip for WiFi and Bluetooth. Configure the
Bluetooth node and enable the UART it is connected to, plus the
necessary pinctrl that has been borrowed with comments from
sc7280-idp.dtsi.
Konrad Dybcio [Wed, 31 May 2023 13:22:42 +0000 (15:22 +0200)]
arm64: dts: qcom: sm8550: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Konrad Dybcio [Wed, 31 May 2023 13:22:41 +0000 (15:22 +0200)]
arm64: dts: qcom: sm6350: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Konrad Dybcio [Wed, 31 May 2023 13:22:40 +0000 (15:22 +0200)]
arm64: dts: qcom: sdm845: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Konrad Dybcio [Wed, 31 May 2023 13:22:39 +0000 (15:22 +0200)]
arm64: dts: qcom: sdm670: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Konrad Dybcio [Wed, 31 May 2023 13:22:38 +0000 (15:22 +0200)]
arm64: dts: qcom: sc8180x: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Konrad Dybcio [Wed, 31 May 2023 13:22:37 +0000 (15:22 +0200)]
arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votes
The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.
Anusha Rao [Fri, 2 Jun 2023 08:44:31 +0000 (14:14 +0530)]
arm64: dts: qcom: ipq9574: add few more reserved memory region
In IPQ SoCs, bootloader will collect the system RAM contents upon crash
for post-morterm analysis. If we don't reserve the memory region used
by bootloader, obviously linux will consume it and upon next boot on
crash, bootloader will be loaded in the same region, which will lead to
loss of some data, sometimes we may miss out critical information.
So lets reserve the region used by the bootloader.
Similarly SBL copies some data into the reserved region and it will be
used in the crash scenario. So reserve 1MB for SBL as well.
While at it, drop the size padding in the reserved memory region,
wherever applicable
Kathiravan T [Mon, 5 Jun 2023 08:05:31 +0000 (13:35 +0530)]
arm64: dts: qcom: ipq5332: add support for the RDP474 variant
Add the initial device tree support for the Reference Design
Platform(RDP) 474 based on IPQ5332 family of SoC. This patch carries
the support for Console UART, eMMC, I2C and GPIO based buttons.
Add the sound card node with tested playback over WSA8845 speakers and
WCD9385 headset over USB Type-C. The recording links were not tested,
but should be similar to previous platforms.
Add the sound card node with tested playback over WSA8845 speakers and
WCD9385 headset over USB Type-C. The recording links were not tested,
but should be similar to previous platforms.
Rohit Agarwal [Fri, 9 Jun 2023 11:50:38 +0000 (17:20 +0530)]
arm64: dts: qcom: Add SDX75 platform and IDP board support
Add basic devicetree support for SDX75 platform and IDP board from
Qualcomm. The SDX75 platform features an ARM Cortex A55 CPU which forms
the Application Processor Sub System (APSS) along with standard Qualcomm
peripherals like GCC, TLMM, UART, QPIC, and BAM etc... Also, there
exists the networking parts such as IPA, MHI, PCIE-EP, EMAC, and Modem
etc..
Bjorn Andersson [Mon, 12 Jun 2023 22:07:39 +0000 (15:07 -0700)]
arm64: dts: qcom: sc8180x: Move DisplayPort for MMCX
The DisplayPort blocks are powered by MMCX and should be described as
such to ensure that power votes are done on the right resource.
This also solves the problem that sync_state is unaware of the DP
controllers needing MMCX to be kept alive during boot. As such this
change also fixes occasionally seen crashes during boot due to
undervoltage of MMCX.
With wider usage on more boards, there have been reports of the
following:
[ 315.016174] qcom-ethqos 20000.ethernet eth0: no phy at addr -1
[ 315.016179] qcom-ethqos 20000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
which has been fairly random and isolated to specific boards.
Early reports were written off as a hardware issue, but it has been
prevalent enough on boards that theory seems unlikely.
In bring up of a newer piece of hardware, similar was seen, but this
time _consistently_. Moving the reset to the mdio bus level (which isn't
exactly a lie, it is the only device on the bus so one could model it as
such) fixed things on that platform. Analysis on sa8540p-ride shows that
the phy's reset is not being handled during the OUI scan if the reset
lives in the phy node:
# gpio 752 is the reset, and is active low, first mdio reads are the OUI
modprobe-420 [006] ..... 154.738544: mdio_access: stmmac-0 read phy:0x08 reg:0x02 val:0x0141
modprobe-420 [007] ..... 154.738665: mdio_access: stmmac-0 read phy:0x08 reg:0x03 val:0x0dd4
modprobe-420 [004] ..... 154.741357: gpio_value: 752 set 1
modprobe-420 [004] ..... 154.741358: gpio_direction: 752 out (0)
modprobe-420 [004] ..... 154.741360: gpio_value: 752 set 0
modprobe-420 [006] ..... 154.762751: gpio_value: 752 set 1
modprobe-420 [007] ..... 154.846857: gpio_value: 752 set 1
modprobe-420 [004] ..... 154.937824: mdio_access: stmmac-0 write phy:0x08 reg:0x0d val:0x0003
modprobe-420 [004] ..... 154.937932: mdio_access: stmmac-0 write phy:0x08 reg:0x0e val:0x0014
Moving it to the bus level, or specifying the OUI in the phy's
compatible ensures the reset is handled before any mdio access
Here is tracing with the OUI approach (which skips scanning the OUI):
The OUI approach is taken given the description matches the situation
perfectly (taken from ethernet-phy.yaml):
- pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
description:
If the PHY reports an incorrect ID (or none at all) then the
compatible list may contain an entry with the correct PHY ID
in the above form.
The first group of digits is the 16 bit Phy Identifier 1
register, this is the chip vendor OUI bits 3:18. The
second group of digits is the Phy Identifier 2 register,
this is the chip vendor OUI bits 19:24, followed by 10
bits of a vendor specific ID.
With this in place the sa8540p-ride's phy is probing consistently, so
it seems the floating reset during mdio access was the issue. In either
case, it shouldn't be floating so this improves the situation. The below
link discusses some of the relationship of mdio, its phys, and points to
this OUI compatible as a way to opt out of the OUI scan pre-reset
handling which influenced this decision.
Introduce support for the Lenovo Flex 5G laptop, built on the Qualcomm
SC8180X platform. Supported peripherals includes keyboard, touchpad,
UFS storage, external USB and WiFi.
Stephan Gerhold [Mon, 29 May 2023 12:47:03 +0000 (14:47 +0200)]
arm64: dts: qcom: msm8916: Move aliases to boards
MSM8939 has the aliases defined separately for each board (because
there could be (theoretically) a board where the slots are numbered
differently. To make MSM8916 and MSM8939 more consistent do the same
for all MSM8916 boards and move aliases there.
All definitions in pm8916.dtsi use the &pm8916_ label prefix, only the
codec uses the &wcd_codec label. &wcd_codec is confusing because the
codec on MSM8916 is split into a "wcd-digital" and "wcd-analog" part
and both could be described with &wcd_codec.
Let's just name it &pm8916_codec so it's consistent with all other PMIC
device nodes.
Stephan Gerhold [Mon, 29 May 2023 12:47:01 +0000 (14:47 +0200)]
arm64: dts: qcom: msm8916/39: Clean up MDSS labels
Right now MDSS related definitions cannot be properly grouped together
in board DTs because the labels do not use consistent prefixes. The DSI
PHY label is particularly weird because the DSI number is at the end
(&dsi_phy0) while DSI itself is called &dsi0.
Follow the example of more recent SoCs and give all the MDSS related
nodes a consistent label that allows proper grouping.
Stephan Gerhold [Mon, 29 May 2023 12:47:00 +0000 (14:47 +0200)]
arm64: dts: qcom: msm8916/39: Use consistent name for I2C/SPI pinctrl
Make the labels for the BLSP I2C/SPI pinctrl consistent with the one
used for UART by adding the missing blsp_ prefix. This allows having
them properly grouped together.
The nodes are only reordered in msm8939.dtsi for now since the pinctrl
definitions in msm8916-pins.dtsi are currently still unordered anyway.
(I will try fixing this in a future patch.)
For some reason the BLSP UART controllers have a label with a number
behind blsp (&blsp1_uartN) while I2C/SPI are named without (&blsp_i2cN).
This is confusing, especially for proper node ordering in board DTs.
Right now all board DTs are ordered as if the number behind blsp does
not exist (&blsp_i2cN comes before &blsp1_uartN). Strictly speaking
correct ordering would be the other way around ('1' comes before '_').
End this confusion by giving the UART controllers consistent labels.
There is just one BLSP on MSM8916/39 so the number is redundant.
Kathiravan T [Tue, 9 May 2023 16:01:33 +0000 (21:31 +0530)]
arm64: dts: qcom: ipq5332: add support for the RDP442 variant
Add the initial device tree support for the Reference Design
Platform(RDP) 442 based on IPQ5332 family of SoC. This patch carries
the support for Console UART, SPI NOR, eMMC and I2C.
arm64: dts: qcom: apq8096: fix fixed regulator name property
Correct the typo in 'regulator-name' property.
apq8096-ifc6640.dtb: v1p05-regulator: 'regulator-name' is a required property
apq8096-ifc6640.dtb: v1p05-regulator: Unevaluated properties are not allowed ('reglator-name' was unexpected)
The bus@0 node should have reg or ranges to fix dtbs W=1 warnings:
Warning (unit_address_vs_reg): /soc@0/bus@0: node has a unit name, but no reg or ranges property
Warning (simple_bus_reg): /soc@0/bus@0: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # MSM8996 Kagura Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230420180746.860934-1-krzysztof.kozlowski@linaro.org
SoC DTSI already comes with 85800000 reserved memory node, so assume the
author wanted to update its length. This fixes dtbs W=1 warning:
Warning (unique_unit_address_if_enabled): /reserved-memory/qhee-code@85800000: duplicate unit-address (also used in node /reserved-memory/reserved@85800000)
Since commit 6c84bbd103d8 ("dt-bindings: arm-smmu: Add generic
qcom,smmu-500 bindings") the SMMU is supposed to use qcom,smmu-500
compatible fallback:
['qcom,sm8250-smmu-500', 'qcom,adreno-smmu', 'qcom,smmu-500', 'arm,mmu-500'] is too long
'qcom,sm8250-smmu-500' is not one of ['qcom,msm8996-smmu-v2', 'qcom,msm8998-smmu-v2', 'qcom,sdm630-smmu-v2']
'qcom,sm8250-smmu-500' is not one of ['qcom,msm8996-smmu-v2', 'qcom,sc7180-smmu-v2', 'qcom,sdm630-smmu-v2', 'qcom,sdm845-smmu-v2'
arm64: dts: qcom: add few more reserved memory region
In IPQ SoCs, bootloader will collect the system RAM contents upon crash
for the post morterm analysis. If we don't reserve the memory region used
by bootloader, obviously linux will consume it and upon next boot on
crash, bootloader will be loaded in the same region, which will lead to
loose some of the data, sometimes we may miss out critical information.
So lets reserve the region used by the bootloader.
Similarly SBL copies some data into the reserved region and it will be
used in the crash scenario. So reserve 1MB for SBL as well.
While at it, drop the size padding in the reserved memory region,
wherever applicable.
arm64: dts: qcom: enable the download mode support
Like any other Qualcomm SoCs, IPQ8074 and IPQ6018 also supports the
download mode to collect the RAM dumps if system crashes, to perform
the post mortem analysis. Add support for the same.
Bhupesh Sharma [Fri, 26 May 2023 19:22:09 +0000 (00:52 +0530)]
arm64: dts: qcom: sm8350: Add Crypto Engine support
Add crypto engine (CE) and CE BAM related nodes and definitions to
'sm8350.dtsi'.
Co-developed-by and Signed-off-by: Robert Foss <rfoss@kernel.org>
[Bhupesh: Switch to '#interconnect-cells = <2>', available since commit 4f287e31ff5f]
Tested-by: Anders Roxell <anders.roxell@linaro.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230526192210.3146896-11-bhupesh.sharma@linaro.org
Devi Priya [Fri, 26 May 2023 15:31:52 +0000 (21:01 +0530)]
arm64: dts: qcom: ipq9574: add support for RDP453 variant
Add the initial device tree support for the Reference Design Platform (RDP)
453 based on IPQ9574 family of SoCs. This patch adds support for Console
UART, SPI NOR and SMPA1 regulator node.
Devi Priya [Tue, 16 May 2023 13:50:13 +0000 (19:20 +0530)]
arm64: dts: qcom: ipq9574: add support for RDP449 variant
Add the initial device tree support for the Reference Design Platform (RDP)
449 based on IPQ9574 family of SoCs. This patch adds support for Console
UART, SPI NOR and SMPA1 regulator node.
Devi Priya [Wed, 10 May 2023 10:43:59 +0000 (16:13 +0530)]
arm64: dts: qcom: ipq9574: add support for RDP418 variant
Add the initial device tree support for the Reference Design Platform (RDP)
418 based on IPQ9574 family of SoCs. This patch adds support for Console
UART, SPI NOR, eMMC and SMPA1 regulator node.
projects / thirdparty / kernel / linux.git / log
