Introduce monaco-ac-evk Board#527
Open
umang-chheda wants to merge 7 commits intoqualcomm-linux:qcom-6.18.yfrom
Open
Introduce monaco-ac-evk Board#527umang-chheda wants to merge 7 commits intoqualcomm-linux:qcom-6.18.yfrom
umang-chheda wants to merge 7 commits intoqualcomm-linux:qcom-6.18.yfrom
Conversation
…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://patch.msgid.link/20260427170505.1494703-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. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260427170505.1494703-3-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@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. Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://patch.msgid.link/20260427170505.1494703-4-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
monaco-ac-evk board supports monaco-evk-ifp-mezzanine attach. Add combined DTB for the same by merging monaco-ac-evk.dtb with monaco-evk-ifp-mezzanine overlay. Link: https://patch.msgid.link/20260427170505.1494703-5-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@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.
Primary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the primary 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, DIP switches are present to select between USB0 and USB1 ports
for the primary Type‑C USB controller. By default, the switches are in
the OFF state, selecting the USB0 port. Add software support for both HS
and SS switches to eliminate the need for manually changing the DIP switch
position for USB1 operation. Add a USB1 hub reset pin to reset and activate
the hub after boot, ensuring proper detection from its pre‑boot inactive
state.
Link: https://lore.kernel.org/r/20260430142000.3707614-1-swati.agarwal@oss.qualcomm.com
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>
The QMP PCIe PHYs on Monaco require a dedicated qref voltage supply for stable operation. Add the vdda-qref-supply for both PCIe PHY instances on the Monaco-evk. Without this supply, the system may occasionally crash mainly in system resume case. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
akdwived-dev
approved these changes
May 5, 2026
akdwived-dev
left a comment
There was a problem hiding this comment.
Seems this needs additional changes from Storage driver for SDHC to work on 2XPMIC Board. rest all look good!
Author
Synced-up with Storage team - currently discussion to enable both eMMC and SD card is going-on with upstream maintainers - so they will be posting patch for SDHC only once the discussion is concluded ... |
Test Matrix
|
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
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.
Add support for Qualcomm's monaco-ac Evaluation Kit (EVK) without
safety monitoring feature of Safety Island(SAIL) subsystem.
This board is based on Qualcomm's QCS8300-AC variant SoC.
Monaco-ac EVK board is a single board computer (SBC) that supports various
industrial applications, including factory automation, industrial
robots, drones, edge AI boxes, machine vision, autonomous mobile
robots (AMRs), and industrial gateways.
Compared to Monaco EVK (monaco-aa):
monaco-aa variant.
(2x PM8654AU + Maxim MAX20018 + TI TPS6594) to 2 PMICs(2x PM8654AU)
Since the two boards share the vast majority of their device tree, this
series first refactors monaco-evk.dts to extract the common hardware
description into monaco-evk-common.dtsi, then introduces monaco-ac-evk.dts.
Also, monaco-ac-evk board supports monaco-evk-ifp-mezzanine attach, Add
support for combined dtb "monaco-ac-evk-ifp-mezzanine" as well, which
overlays monaco-evk-ifp-mezzanine on top of monaco-ac-evk DT.
CRs-Fixed: 4489525