FROMLIST: arm64: dts: qcom: monaco: add GDSP fastrpc-compute-cb nodes#1051
Closed
quic-vkatoch wants to merge 30 commits intoqualcomm-linux:tech/all/dt/qcs8300from
Closed
FROMLIST: arm64: dts: qcom: monaco: add GDSP fastrpc-compute-cb nodes#1051quic-vkatoch wants to merge 30 commits intoqualcomm-linux:tech/all/dt/qcs8300from
quic-vkatoch wants to merge 30 commits intoqualcomm-linux:tech/all/dt/qcs8300from
Conversation
Add support for SYSTEM_RESET2 vendor-specific resets as reboot-modes in the psci node. Describe the resets: "bootloader" will cause device to reboot and stop in the bootloader's fastboot mode. "edl" will cause device to reboot into "emergency download mode", which permits loading images via the Firehose protocol. Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-11-46e085bca4cc@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
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. Link: https://lore.kernel.org/r/20251126081057.4191122-3-quic_vikramsa@quicinc.com Signed-off-by: Nihal Kumar Gupta <quic_nihalkum@quicinc.com> Co-developed-by: Ravi Shankar <quic_rshankar@quicinc.com> Signed-off-by: Ravi Shankar <quic_rshankar@quicinc.com> Co-developed-by: Vishal Verma <quic_vishverm@quicinc.com> Signed-off-by: Vishal Verma <quic_vishverm@quicinc.com> Co-developed-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa@quicinc.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
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. An example media-ctl pipeline for the imx577 is: media-ctl --reset media-ctl -V '"imx577 3-001a":0[fmt:SRGGB10/4056x3040 field:none]' media-ctl -V '"msm_csiphy1":0[fmt:SRGGB10/4056x3040]' media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]' media-ctl -l '"msm_csiphy1":1->"msm_csid0":0[1]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video1 Link: https://lore.kernel.org/r/20251126081057.4191122-4-quic_vikramsa@quicinc.com Signed-off-by: Nihal Kumar Gupta <quic_nihalkum@quicinc.com> Co-developed-by: Ravi Shankar <quic_rshankar@quicinc.com> Signed-off-by: Ravi Shankar <quic_rshankar@quicinc.com> Co-developed-by: Vishal Verma <quic_vishverm@quicinc.com> Signed-off-by: Vishal Verma <quic_vishverm@quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa@quicinc.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Enable WLAN on qcs8300-ride by adding a node for the PMU module of the WCN6855 and assigning its LDO power outputs to the existing WiFi module. On the qcs8300-ride platform, the corresponding firmware and BDF are QCA6698AQ instead of WCN6855, which have been added in the 20250211 release. Link: https://lore.kernel.org/r/20260225071459.1600394-1-wei.zhang@oss.qualcomm.com Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies. Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module. The module provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Link: https://lore.kernel.org/all/20251113130519.2647081-1-wei.deng@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
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. Link: https://lore.kernel.org/all/20251118140406.1551669-2-wei.deng@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…ice nodes Add device tree nodes for the DSI0 controller with their corresponding PHY found on Qualcomm QCS8300 SoC. Link: https://lore.kernel.org/r/20260217090955.2446470-2-quic_amakhija@quicinc.com Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
…e node Add anx7625 DSI to DP bridge device node. Link: https://lore.kernel.org/r/20260217090955.2446470-3-quic_amakhija@quicinc.com Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Monaco-evk has LT8713sx which act as DP to 3 DP output converter. Edp PHY from monaco soc is connected to lt8713sx as input and output of lt8713sx is connected to 3 mini DP ports. Two ports are available in mainboard and one port is available on Mezz board. lt8713sx is connected to soc over i2c0 and with reset gpio connected to pin6 of ioexpander5. Enable the edp nodes from monaco and enable lontium lt8713sx bridge node. Link: https://lore.kernel.org/r/20251228-lt8713sx-bridge-linux-for-next-v3-1-3f77ad84d7d1@oss.qualcomm.com Co-developed-by: Prahlad Valluru <vvalluru@qti.qualcomm.com> Signed-off-by: Prahlad Valluru <vvalluru@qti.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
The Qualcomm SerDes PHY, present on multiple boards, has two regulators providing supplies of 1.2V (L5A) and 0.9V (L4A). Update the node to reflect the same instead of incorrectly voting for only L4A. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-4-73ae8f9cbe2a@oss.qualcomm.com Fixes: 117d6bc ("arm64: dts: qcom: qcs8300: Add Monaco EVK board") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…egulator Add the additional 0.9V regulator for the Qualcomm SerDes PHY. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-5-73ae8f9cbe2a@oss.qualcomm.com Fixes: 787cb3b ("arm64: dts: qcom: qcs8300-ride: enable ethernet0") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
PCIe phy needs to be voted for QREF regulator, As the base dtsi changes are still pending we haven't posted the actual fix. Till we post actual fix to upstream, use this change as a workaround. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Enable cdsp cooling devices and thermal zone cooling map bindings for cdsp. Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251223123227.1317244-9-gaurav.kohli@oss.qualcomm.com/
…bypass pwrseq flow There is a conflict between the current DTS configuration and the driver behavior for the WCN6855 Bluetooth path. With the PMU node in place, the driver takes the pwrseq code path unintentionally, which leads to Bluetooth failing to power up during an on -> off -> on transition. To unblock function, temporarily remove the WCN6855 PMU node so that the driver follows the non-pwrseq path and avoids the unexpected sequence. This is a TEMPORARY WORKAROUND. Once a proper M.2 binding/solution is upstreamed, will re-submit both DTS and driver changes aligned with the M.2 model. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
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. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Link: https://lore.kernel.org/lkml/20260127-talos-el2-overlay-v2-2-b6a2266532c4@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Currently pcie1 global IRQ is blocking a CPU core, due to which ufs is getting blocked and failing. As workaround disable PCIe1 global IRQ for now. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
The IFP Mezzanine is an hardware expansion add-on board designed
to be stacked on top of Monaco EVK.
It has following peripherals :
- 4x Type A USB ports in host mode.
- TC9563 PCIe switch, which has following three downstream ports (DSP) :
- 1st DSP is routed to an M.2 E-Key connector, intended for
WLAN modules.
- 2nd DSP is routed to an M.2 B-key connector, intended for
cellular modems.
- 3rd DSP with support for Dual Ethernet ports.
- EEPROM.
- LVDS Display.
- 2*mini DP.
Add support for following peripherals :
- TC9563 PCIe Switch.
- EEPROM.
Enable support for USB hub, LVDS display and mini-DP later once dependent
changes are available in monaco-evk core-kit.
Written with inputs from :
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> - PCIe
Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
Link: https://lore.kernel.org/r/20260303164314.886733-2-umang.chheda@oss.qualcomm.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
…t for Monaco EVK 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. Link: https://lore.kernel.org/all/20260210155329.3044455-2-swati.agarwal@oss.qualcomm.com/ Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
…oller Enable the tertiary usb controller connected to micro usb port in OTG mode on Monaco EVK platform. Link: https://lore.kernel.org/all/20260210155329.3044455-3-swati.agarwal@oss.qualcomm.com/ Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
… in host mode Enable primary USB controller in host mode on monaco EVK Platform. Primary USB controller is connected to a Genesys Logic USB HUB GL3590 having 4 ports. The ports of hub that are present on lemans EVK standalone board are used as follows:- 1) port-1 is connected to HD3SS3220 Type-C port controller. 2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART for Bluetooth. This port is to be used only if user optionally replaces the WiFi card with the NFA765 chip which uses USB for Bluetooth. Remaining 2 ports will become functional when the interface plus mezzanine board is stacked on top of corekit: 3) port-2 is connected to another hub which is present on the mezz through which 4 type-A ports are connected. 4) port-3 is used for the M.2 B key for a 5G card when the mezz is connected. Mark the second USB controller as host only capable and add the HD3SS3220 Type-C port controller along with Type-c connector for controlling vbus supply. In hardware, there are dip switches provided to operate between USB port 0 and port 1 for primary Type-C USB controller. By default, switches will be off operating at USB0 port. After bootup to HLOS, it will be operated in USB1 port. Added support in the software for both HS and SS switches as usb1-hs-high-gpio14 and usb1-ss-high-gpio5. Also, added bootup-high-gpio7 pin for USB1 hub reset to get detected after bootup. Link: https://lore.kernel.org/all/20260210152548.769951-1-loic.poulain@oss.qualcomm.com/ Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
Add clocks which need to be enabled for configuring QoS on qcs8300 SoC. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-4-odelu.kukatla@oss.qualcomm.com
The monaco-evk mezzanine connector supports a robot expansion board that requires UART6, which is currently disabled. This prevents the expansion board from exchanging data and control commands. Enable UART6 and assign the serial2 alias to provide stable device enumeration for the expansion board. Link: https://lore.kernel.org/all/20260327083101.1343613-3-canfeng.zhuang@oss.qualcomm.com/ Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
Add support for IRIS on monaco when Linux host running at EL2. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
…nto shared dtsi The monaco-ac EVK is a new board variant which shares the majority of its hardware description with the existing monaco-evk board. In preparation for adding this variant, extract the common hardware nodes from monaco-evk.dts into a new shared monaco-evk-common.dtsi include file, and update monaco-evk.dts to include it and keep only board-specific overrides. No functional change intended. Link: https://lore.kernel.org/lkml/20260413114819.3894307-2-umang.chheda@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Introduce bindings for the monaco-ac-evk IoT board, which is based on the monaco-ac (QCS8300-AC) SoC variant. Link: https://lore.kernel.org/lkml/20260413114819.3894307-3-umang.chheda@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Add initial device tree support for monaco-ac EVK board, based on Qualcomm's monaco-ac (QCS8300-AC) variant SoC. Compared to the existing monaco-evk board, which is based on the QCS8300-AA SKU and uses a four-PMIC power delivery network (2x PM8650AU, Maxim MAX20018, TI TPS6594) to support higher power requirements, the monaco-ac EVK uses QCS8300-AC SKU (with 20 TOPS NPU capability) and a simplified two-PMIC power delivery network (2x PM8650AU). Apart from the SoC SKU and PDN differences, the board layout and peripherals are equivalent to the monaco-evk design and are reused accordingly. Link: https://lore.kernel.org/lkml/20260413114819.3894307-4-umang.chheda@oss.qualcomm.com/ Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…b2 HS PHY Problem Statement:- After the Introduction of commits (1 and 2) ADB goes offline a few seconds after USB enumeration on the micro‑USB (USB2) port. The failure is consistently observed shortly after enumeration, with the following log indicating regulator shutdown: [ 40.220063][ T49] refgen: disabling On RB4, ADB operates over the USB2 HSPHY, which requires three power rails: 0.8 V (vdda‑pll) 1.8 V (vdda18) 3.3 V (vdda33) Based on the current DTS configuration, the USB2 HS PHY regulators are as follows as per monaco power grid: vdda-pll-supply (0.8 V): l7a vdda18-supply (1.8 V): l7c vdda33-supply (3.3 V): l9a However, according to the Monaco power grid analysis, the regulators for the USB2 HS PHY should be: vdda-pll-supply (0.8 V): l4a vdda18-supply (1.8 V): s4a vdda33-supply (3.3 V): l8a This mismatch in regulator assignment results in unstable PHY power, causing ADB to drop offline shortly after USB enumeration. Workaround solution:- As an interim workaround, the refgen regulator is used for the 0.8 V (vdda‑pll) rail instead of l7a. This change restores stable USB2 HS PHY operation and prevents ADB from disconnecting. Presently this is taken as a workaround while we confirm the mismatch in the power grid understanding. 1) fc406be (add Display Serial Interface device nodes) 2) 2c9e4d7 (add refgen regulator) Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, define the necessary device tree nodes, including UART configuration and power supplies. The module provides a 3.3V supply originating from the main board's 12V rail. Add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node to represent this power hierarchy. Workaround: With the WCN6855 PMU node present, the driver unintentionally takes the pwrseq code path, which causes Bluetooth to fail to power up during an on -> off -> on transition. To unblock functionality, the PMU node is omitted and all Bluetooth power supply references point directly to vreg_wcn_3p3, keeping the driver on the non-pwrseq path. This is a temporary workaround. Once a proper M.2 binding/solution is upstreamed, both DTS and driver changes will be re-submitted aligned with the M.2 model. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…icator Fix the wrong connection for the qdss replicator device. Link: https://lore.kernel.org/all/20260427-fix-monaco-coresight-dt-v1-1-1707017f20c5@oss.qualcomm.com/ Fixes: 0f43254 ("arm64: dts: qcom: qcs8300: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Add GDSP fastrpc compute-cb nodes for monaco SoC. Link: https://lore.kernel.org/all/20260415-monacogdsp-v1-1-077ded36c7fc@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
qcomlnxci
requested review from
a team,
idlethread,
knaveen-qc and
quicAspratap
and removed request for
a team
Chennak-quic
previously approved these changes
Apr 30, 2026
shashim-quic
dismissed
Chennak-quic’s stale review
The merge-base changed after approval.
shashim-quic
force-pushed
the
tech/all/dt/qcs8300
branch
from
fbd30b5 to
90ba006
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Patch: Add GDSP FastRPC compute‑cb nodes for the Monaco SoC.
Link: https://lore.kernel.org/all/20260415-monacogdsp-v1-1-077ded36c7fc@oss.qualcomm.com/