The restriction on UHS-I speed modes was added to all SM8550 platforms
by copying it from SM8450 dtsi file, and due to the overclocking of SD
cards it was an actually reproducible problem. Since the latter issue
has been fixed, UHS-I speed modes are working fine on SM8550 boards,
below is the test performed on SM8550-HDK:
SDR50 speed mode:
mmc0: new UHS-I speed SDR50 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.6 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
SDR104 speed mode:
mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
mmcblk0: mmc0:59b4 USDU1 28.3 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
file, there is no indication that the SDHC controller is broken.
Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-6-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The reported problem of some non-working UHS-I speed modes on SM8450
originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
SDHCI SDR104/SDR50 on all boards").
The tests show that the rootcause of the problem was related to an
overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
Since then both SDR50 and SDR104 speed modes are working fine on SM8450,
tested on SM8450-HDK:
SDR50 speed mode:
mmc0: new UHS-I speed SDR50 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.6 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s
SDR104 speed mode:
mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
mmcblk0: mmc0:59b4 USDU1 28.3 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s
Remove the restrictions on SD card speed modes from the SM8450 platform
dtsi file and enable UHS-I speed modes.
Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: hamoa: Fix xo clock supply of platform SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: ffb21c1e19b1 ("arm64: dts: qcom: x1e80100: Describe the SDHC controllers") Reported-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8650: Fix xo clock supply of SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8550: Fix xo clock supply of platform SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Konrad Dybcio [Tue, 17 Mar 2026 14:41:16 +0000 (15:41 +0100)]
arm64: dts: qcom: sm8450: Fix GIC_ITS range length
Currently, the GITS_SGIR register is cut off. Fix it up.
Fixes: fc8b0b9b630d ("arm64: dts: qcom: sm8450 add ITS device tree node") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-3-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8750-mtp: Enable USB headset and Type-C accessory mode
MTP8750 does not have audio jack connected and relies on USB mux
(WCD9395). Add necessary nodes for proper audio headset support along
with USB Type-C accessory mode and orientation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260317-sm8750-display-dts-v5-3-fb53371e251c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:13 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8750: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:12 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8650: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:11 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8550: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:10 +0000 (17:27 +0200)]
arm64: dts: qcom: monaco: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:09 +0000 (17:27 +0200)]
arm64: dts: qcom: lemans: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-2-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:08 +0000 (17:27 +0200)]
arm64: dts: qcom: hamoa: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Abel Vesa [Wed, 18 Mar 2026 10:19:34 +0000 (12:19 +0200)]
arm64: dts: qcom: eliza: Enable Eliza MTP board support
The MTP is a one of the boards that comes with the Eliza SoC.
So add dedicated board dts for it.
The initial support enables:
- UART debug console
- Ob-board UFS storage
- Qualcomm RPMh regulators (PMIC) and VPH_PWR
- board specific clocks & reserved GPIO ranges
Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260318-eliza-base-dt-v3-3-8a50bd2201ed@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Abel Vesa [Wed, 18 Mar 2026 10:19:33 +0000 (12:19 +0200)]
arm64: dts: qcom: Introduce Eliza Soc base dtsi
Introduce the initial support for the Qualcomm Eliza SoC. It comes in
different flavors. There is SM7750 for mobiles and then QC7790S/M for IoT.
Describe the common parts under a common dtsi.
The initial submission enables support for:
- CPU nodes with cpufreq and cpuidle support
- Global Clock Controller (GCC)
- Resource State Coordinator (RSC) with clock controller & genpd provider
- Interrupt controller
- Power Domain Controller (PDC)
- Vendor specific SMMU
- SPMI bus arbiter
- Top Control and Status Register (TCSR)
- Top Level Mode Multiplexer (TLMM)
- Debug UART
- Reserved memory nodes
- Interconnect providers
- System timer
- UFS
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260318-eliza-base-dt-v3-2-8a50bd2201ed@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Abel Vesa [Wed, 18 Mar 2026 10:19:32 +0000 (12:19 +0200)]
dt-bindings: arm: qcom: Document Eliza SoC and its MTP board
Qualcomm Eliza SoC comes with different flavors. There is SM7750 for
mobiles and then QC7790S/M for IoT. One of the boards that comes with
Eliza SoC is the MTP.
So document both the SoC and MTP board compatibles.
Bjorn Andersson [Thu, 19 Mar 2026 02:26:37 +0000 (21:26 -0500)]
Merge branch 'icc-eliza' of https://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into HEAD
Merge the Eliza interconnect DeviceTree bindings from topic branch, in
order to introduce the interconnect constants used in the Eliza
DeviceTree source.
Introduce support for the Mahua SoC and the CRD based on it. Some of
the notable differences are the absent CPU cluster, interconnect, TLMM,
thermal zones and adjusted PCIe west clocks. Everything else should
work as-is.
dt-bindings: arm: qcom: Document Mahua SoC and board
Mahua is a derivative of Glymur SoC with the third CPU cluster disabled.
Document the compatible strings for the Mahua SoC and the Compute
Reference Device (CRD) board based on it.
Wei Deng [Mon, 2 Mar 2026 02:46:58 +0000 (08:16 +0530)]
arm64: dts: qcom: qcs8300-ride: Enable Bluetooth support
Enable BT on qcs8300-ride by adding a BT device tree node.
Since the platform uses the QCA6698 Bluetooth chip. While
the QCA6698 shares the same IP core as the WCN6855, it has
different RF components and RAM sizes, requiring new firmware
files. Use the firmware-name property to specify the NVM and
rampatch firmware to load.
Tobias Heider [Thu, 26 Feb 2026 14:04:30 +0000 (15:04 +0100)]
arm64: dts: qcom: add missing denali-oled.dtb to Makefile
The DeviceTree for the OLED variant of the Microsoft Surface Pro 11th
Edition was originally added in commit '0d72ccaa1e84 ("arm64: dts: qcom:
Add support for X1-based Surface Pro 11")'. The original patch on the
mailing list also added the new device tree to the Makefile but that
part seems to have been dropped (by accident) when it got merged.
Signed-off-by: Tobias Heider <tobias.heider@canonical.com> Fixes: 0d72ccaa1e84 ("arm64: dts: qcom: Add support for X1-based Surface Pro 11") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260226140429.232544-3-tobias.heider@canonical.com
[bjorn: Rewrote commit message reference to offending commit] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Erikas Bitovtas [Wed, 25 Feb 2026 14:43:24 +0000 (16:43 +0200)]
arm64: dts: qcom: msm8939-asus-z00t: add ambient light and proximity sensor
This device uses Capella CM36686 as its ambient light and proximity
sensor. It is fully compatible with Vishay VCNL4040. Downstream device
tree reports Capella CM36283, but upon probe, a device ID for CM36686 is
actually found. This commit adds support for Capella CM36686 ambient
light and proximity sensor.
Monaco EVK board does not include a camera sensor in its default hardware
configuration. Introducing a device tree overlay to support optional
integration of the IMX577 sensor via CSIPHY1.
Camera reset is handled through an I2C expander, and power is enabled
via TLMM GPIO74.
Qualcomm QCS8300 SoC contains three Camera Control Interface (CCI).
Compared to Lemans, the key difference is in SDA/SCL GPIO assignments
and number of CCIs.
Luca Weiss [Fri, 13 Feb 2026 14:03:19 +0000 (15:03 +0100)]
arm64: dts: qcom: milos: Sort pinctrl subnodes by pins
As documented in the "Devicetree Sources (DTS) Coding Style" document,
pinctrl subnodes should be sorted by the pins property. Do this once for
milos.dtsi so that future additions can be added at the right places.
Aruino Uno-Q uses Analogix ANX7625 DSI-to-DP bridge to convert DSI
signals to the connected USB-C DisplayPort dongles. Decribe the chip,
USB-C connector and routing of USB and display signals.
Xueyao An [Thu, 12 Feb 2026 08:25:57 +0000 (16:25 +0800)]
arm64: dts: qcom: hamoa-iot-som: Add firmware-name to QUPv3 nodes
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
arm64: dts: qcom: x1e80100: Add '#cooling-cells' for CPU nodes
Enable passive cooling for CPUs in the X1E80100 SoC by adding the
'#cooling-cells' property. This will allow the OS to mitigate the CPU
power dissipation with the help of SCMI DVFS.
Roger Shimizu [Sat, 7 Feb 2026 10:45:28 +0000 (02:45 -0800)]
arm64: dts: qcom: qcs6490: Add Thundercomm AI Mini PC G1 IoT
Thundercomm AI MiniPC G1 IoT is single board computer with
AI capability based on Qualcomm QCS6490 platform.
This device tree is confirmed to work as below:
- GPU
- HDMI output port
- PCIe M.2 port (for external Wi-Fi or 5G connectivity)
- UART / serial console port
- UFS
- USB Type-C port, with Display Port
RDP433/RDP418 can have NAND or eMMC based on a board level rework. Since
the same GPIOS are used for both the interfaces, only one of them can be
used. Add a new DTS file to enable eMMC.
arm64: dts: qcom: ipq9574-rdp433: Reorganize DTS to introduce eMMC support
The RDP433 has NAND and eMMC variants. Presently, only NAND variant is
supported. To enable support for eMMC variant, move the common nodes from
ipq9574-rdp433.dts to ipq9574-rdp433-common.dtsi. ipq9574-rdp433-common.dtsi
will be included in rdp433 NAND and eMMC DT files.
RDP433 and RDP418 has NAND and eMMC variants. Presently, only NAND
variant is supported. To enable support for eMMC variant, add the
relevant GPIO and regulator information.
Do not enable NAND or eMMC by default in ipq9574-rdp-common.dtsi. Enable
it in board specific DTS as applicable.
The backlight on this device is connected via 3 strings. Currently,
the DT claims only two are present, which results in visible stripes
on the display (since every third backlight string remains unconfigured).
Xilin Wu [Wed, 28 Jan 2026 19:11:28 +0000 (13:11 -0600)]
arm64: dts: qcom: sm8550: Update EAS properties
The original values provided by Qualcomm appear to be quite
inaccurate. Specifically, some heavy gaming tasks could be
improperly assigned to the A510 cores by the scheduler, resulting
in a CPU bottleneck. This update to the EAS properties aims to
enhance the user experience across various scenarios.
The power numbers were obtained using a Type-C power meter, which
was directly connected to the battery connector on the AYN Odin 2
motherboard, acting as a fake battery.
It should be noted that the A715 cores seem less efficient than the
A710 cores. Therefore, an average value has been assigned to them,
considering that the A715 and A710 cores share a single cpufreq
domain.
Xin Liu [Tue, 3 Feb 2026 06:32:44 +0000 (22:32 -0800)]
arm64: dts: qcom: hamoa: Add remoteproc IOMMUS in EL2 device trees
All the existing variants Hamoa boards are using Gunyah hypervisor
which means that, so far, Linux-based OS could only boot in EL1 on
those devices. However, it is possible for us to boot Linux at EL2
on these devices [1].
When running under Gunyah, the remote processor firmware IOMMU streams
are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
by the consumer of this DeviceTree. Therefore, describe the firmware
streams for each remote processor.
Add remoteproc IOMMUS to the EL2 device trees to generate the
corresponding -el2.dtb files.
Sibi Sankar [Fri, 13 Mar 2026 10:34:39 +0000 (16:04 +0530)]
arm64: dts: qcom: glymur: Fix deprecated cpu compatibles
The generic Qualcomm Oryon CPU compatible used by the Glymur
SoC is deprecated and incorrect since it uses a single compatible
to describe two different core variants. It is now replaced with
two different core-specific compatibles based on MIDR part and
variant number.
The generic Qualcomm Oryon CPU compatible documented in the binding
doesn't account for differences between core types and has been
deprecated. Introduce core-specific compatibles, by appending the
compatible with MIDR part and variant numbers as listed below.
To make sure the display subsystem starts in a predictable state, we
need to reset it. Otherwise, unpredictable issues can happen, e.g.
on the xiaomi-laurel-sprout smartphone DSI would not work on boot.
To make sure the display subsystem starts in a predictable state, we
need to reset it. Otherwise, unpredictable issues can happen, e.g.
on the motorola-guamp smartphone DSI would not transmit anything.
Add the missing defines for MDSS resets, which are necessary to reset
the display subsystem in order to avoid issues caused by state left over
from the bootloader.
Add the missing defines for MDSS resets, which are necessary to reset
the display subsystem in order to avoid issues caused by state left over
from the bootloader.
Taniya Das [Wed, 11 Mar 2026 14:46:31 +0000 (16:46 +0200)]
dt-bindings: clock: qcom: document the Eliza Global Clock Controller
Add bindings documentation for the Global Clock Controller on Qualcomm
Eliza SoC. Reuse the Milos bindings schema since the controller resources
are exactly the same, even though the controllers are incompatible between
them.
DisplayPort Reduced Bit Rate uses link rate of 1.62 Gbps, the main link
clock should be 162 MHz. Having the incorrect frequency (160 MHz) in the
OPP table will result in selecting wrong link frequency. Correct the
entry in the OPP table.
Enable PCA9538 expander as interrupt controller on Monaco EVK and configure
the corresponding TLMM pins via pinctrl to operate as GPIO inputs with
internal pull-ups.
arm64: dts: qcom: qcm6490-idp: add and enable BT node
Add the PMU node for WCN6750 present on the qcm6490-idp
board and assign its power outputs to the Bluetooth module.
In WCN6750 module sw_ctrl and wifi-enable pins are handled
in the wifi controller firmware. Therefore, it is not required
to have those pins' entries in the PMU node.
Odelu Kukatla [Tue, 24 Feb 2026 11:43:06 +0000 (13:43 +0200)]
dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Eliza SoC
Document the RPMh Network-On-Chip Interconnect of the Eliza platform.
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://msgid.link/20260224-eliza-interconnect-v4-1-ad75855d5018@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
Mukesh Ojha [Tue, 27 Jan 2026 11:43:49 +0000 (17:13 +0530)]
arm64: dts: qcom: monaco: Add EL2 overlay
All the Monaco IOT variants boards are using Gunyah hypervisor which
means that, so far, Linux-based OS could only boot in EL1 on those
devices. However, it is possible for us to boot Linux at EL2 on these
devices [1].
When running under Gunyah, the remote processor firmware IOMMU streams
are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
by the consumer of this DeviceTree. Therefore, describe the firmware
streams for each remote processor.
Add a EL2-specific DT overlay and apply it to Monaco IOT variant
devices to create -el2.dtb for each of them alongside "normal" dtb.
Xin Liu [Tue, 27 Jan 2026 06:24:25 +0000 (22:24 -0800)]
arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-evk
Add support for building an EL2 combined DTB for the hamoa-evk
in the Qualcomm DTS Makefile.
The new hamoa-iot-evk-el2.dtb is generated by combining the base
hamoa-iot-evk.dtb with the x1-el2.dtbo overlay, enabling EL2-specific
configurations required by the platform.
Konrad Dybcio [Mon, 26 Jan 2026 09:45:03 +0000 (10:45 +0100)]
arm64: dts: qcom: talos: Add missing clock-names to GCC
The binding for this clock controller requires that clock-names are
present. They're not really used by the kernel driver, but they're
marked as required, so someone might have assumed it's done on purpose
(where in reality we try to stay away from that since index-based
references are faster, take up less space and are already widely used)
and referenced it in drivers for another OS.
Hence, do the least painful thing and add the missing entries.
projects / thirdparty / kernel / linux.git / log
