UPSTREAM: arm64: dts: qcom: monaco: Remove the little/big_cpu_sleep_0 idle states - #1767
Closed
maulik-k-shah wants to merge 36 commits into
Closed
UPSTREAM: arm64: dts: qcom: monaco: Remove the little/big_cpu_sleep_0 idle states#1767maulik-k-shah wants to merge 36 commits into
maulik-k-shah wants to merge 36 commits into
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>
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>
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>
Unlike the CPU, the CDSP does not throttle its speed automatically when it reaches high temperatures in monaco. Set up CDSP cooling for both instances by throttling the cdsp, when it reaches 115°C. Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260609-qmi-tmd-v3-7-291a2ff4c634@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>
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>
… 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 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. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427170505.1494703-2-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.
monaco-ac EVK is single board supporting these peripherals :
- Storage: 1 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
and eMMC.
- Audio/Video, Camera & Display ports.
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD.
- PCIe ports.
- USB & UART ports.
Compared to "monaco-evk" variant, which utilizes higher tier QCS8300-AA
SKU (supporting 40 TOPS of NPU) and a 4-PMIC (2x PM8650AU + Maxim MAX20018
+ TI TPS6594) power delivery network (PDN) to support higher power
requirement. This board utilizes lower tier QCS8300-AC SKU
(Supporting 20 TOPS of NPU) and a simplified 2 PMIC(2x PM8650AU) PDN.
Add support for the following components :
- GPI (Generic Peripheral Interface) and QUPv3-0/1
controllers to facilitate DMA and peripheral communication.
- TCA9534 I/O expander via I2C to provide 8 additional GPIO
lines for extended I/O functionality.
- USB1 controller routed to a TypeC connector in device mode to
support USB peripheral operations.
- Remoteproc subsystems for supported DSPs such as Audio DSP,
Compute DSP and Generic DSP, along with their corresponding
firmware.
- Configure nvmem-layout on the I2C EEPROM to store data for Ethernet
and other consumers.
- QCA8081 2.5G Ethernet PHY on port-0 and expose the
Ethernet MAC address via nvmem for network configuration.
It depends on CONFIG_QCA808X_PHY to use QCA8081 PHY.
- Support for the Iris video decoder, including the required
firmware, to enable video decoding capabilities.
- PCIe0 and PCIe1 controller and phy-nodes.
- Sound card and max98357a based I2S speaker amplifier.
Written with inputs from:
Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> - GPIO
Expander.
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> - GPI/QUP.
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> - Ethernet.
Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
Swati Agarwal <swati.agarwal@oss.qualcomm.com> - USB.
Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com> - PCIe.
Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> - Audio.
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>
Link: https://lore.kernel.org/r/20260626111301.3479559-3-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> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260626111301.3479559-2-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. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427170505.1494703-5-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. Fixes: 4f791e0 ("arm64: dts: qcom: monaco: Add CTCU and ETR nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260428-fix-monaco-coresight-dt-v2-1-2293259bbd10@oss.qualcomm.com
… board DT The Monaco SoC SDHC controller supports both eMMC and SD cards. However, the 'supports-cqe' property (Command Queue Engine) is specific to eMMC and conflicts with SD card operation. Remove 'supports-cqe' from the SoC device tree to ensure compatibility with SD cards. Simultaneously, add the property explicitly to the qcs8300-ride and monaco-monza-som board device tree, as this board uses the controller in eMMC mode. This ensures the SoC definition remains generic while enabling features correctly at the board level. Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701081715.2580329-2-monish.chunara@oss.qualcomm.com
…overlay The monaco EVK board supports either eMMC or SD-card, but only one can be active at a time. Enable the SD Host Controller Interface (SDHCI) on the monaco EVK board to support SD Card for storage via a device tree overlay. This allows eMMC support to be enabled through a separate overlay when required. Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701081715.2580329-3-monish.chunara@oss.qualcomm.com
…a overlay Enable the SDHCI controller for eMMC functionality on the Monaco EVK using a device tree overlay. Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260701081715.2580329-4-monish.chunara@oss.qualcomm.com
Add AEST RAS error source nodes for the Monaco SoC. The DT describes a processor error source covering all CPU cores and a shared L3 cache error source for the cluster. These nodes model the hardware error reporting blocks and associated interrupts as required by the Arm AEST specification. Link: https://lore.kernel.org/all/20260505-aest-devicetree-support-v1-8-d5d6ffacf0a5@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>
Add pinctrl states for the GP M/N divider clock output pin across multiple Qualcomm SoCs: wire it to the GP M/N clock controller node via pinctrl-0. - kodiak (sa8775p): Add gp_mn_active state on gpio35 (gp_mn function). - lemans (sa8775p): Add gp_mn_active state on gpio35 (gp_mn function). - monaco (qcs8300): Add gp_mn_active state on gpio32 (gp_mn function). Link: https://lore.kernel.org/r/20260602-pdm_clk_gp_mnd_v1-v1-4-1522662b6c53@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…75P and QCS8300 Add the GP M/N divider clock controller node at 0x088d3000 to the SA8775P (kodiak, lemans) and QCS8300 (monaco) SoC device trees. The node uses the qcom,clk-gp-mnd compatible, is clocked by the PDM XO4 and AHB clocks from GCC, and exposes a single clock output (gp_mn_clk) on the dedicated gp_mn pin mux function. The XO4 clock is pre-assigned to 4.8 MHz (XO/4). Link: https://lore.kernel.org/r/20260602-pdm_clk_gp_mnd_v1-v1-5-1522662b6c53@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…no SMMU On Monaco platforms, the Adreno SMMU requires a bandwidth vote on the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers are accessible. Without this vote, the SMMU may become unreachable, leading to intermittent probe failures and runtime issues. Add the required interconnect to ensure reliable register access. Link: https://lore.kernel.org/all/20260526-smmu_interconnect_addition-v2-5-2a6d8ca30d63@oss.qualcomm.com/ Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
… devices Add label properties to TPDM and CTI nodes in the monaco device tree to provide human-readable identifiers for each CoreSight device. These labels allow userspace tools and the CoreSight framework to identify devices by name rather than by base address. Link: https://lore.kernel.org/linux-arm-msm/20260414-add-label-to-coresight-device-v2-3-5017d07358f2@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
…d SMMU mappings The audio ML (machine-learning) offload use case requires a contiguous, physically addressable buffer shared with the audio DSP/SPF, and issues DMA transactions through additional SMMU stream IDs that are not covered by the existing ADSP mapping. Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB aligned) and wire it to the q6apm DAIs node via memory-region. A dedicated pool guarantees the alignment and contiguity the DSP expects and isolates these allocations from the default CMA region. Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully enforcing, so the ML transactions are otherwise blocked and faulted: arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2060 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2062 Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the remoteproc_adsp iommus property in the EL2 overlay so these buffers are translated by the SMMU instead of being rejected. Link: https://lore.kernel.org/all/20260717095825.3962666-4-pratyush.meduri@oss.qualcomm.com/ Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
The Iris VPU has separate streams with different IOVA constraints. The non-pixel stream must be limited to the 0-600 MB IOVA range, while the pixel stream can use the full IOVA space. Using a single set of IOMMU entries for the Iris node does not describe these per-stream limits and can allow accesses outside the supported range, which may lead to device crashes. One such issue was reported at: https://gitlab.freedesktop.org/drm/msm/-/work_items/100 Add non-pixel and pixel child nodes, move each stream ID to its corresponding child node, and add a reserved IOVA range for the non-pixel stream. Link: https://lore.kernel.org/all/20260709-vpu_iommu_iova_handling-v1-10-72bb62cb2dfd@oss.qualcomm.com/ Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Tested-by: Daniel J Blueman <daniel@quora.org>
Add 'compatible = "pciclass,0604"' to the pcieport0 node in monaco.dtsi to allow the PCI subsystem to associate the DT node with the PCI-to-PCI bridge device. This is required for downstream DT nodes (such as M.2 connectors described as graph endpoints of the Root Port) to be matched to PCI devices. Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-1-0548e1dab760@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…o pcieport0 and uart2 Add empty graph port/endpoint nodes to pcieport0 and uart2 in monaco.dtsi so that board files can reference the endpoint labels (pcieport0_ep, uart2_ep) to describe connections to M.2 Key E connectors via remote-endpoint overrides. Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-2-0548e1dab760@oss.qualcomm.com/ Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…etooth support" This reverts commit 3db807c. The previous workaround is superseded by the proper M.2 Key E connector DT solution (see following commit). Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…onnector The monaco EVK has a PCIe M.2 Mechanical Key E connector to connect wireless connectivity cards over PCIe and UART interfaces. Hence, describe the connector node and link it with the PCIe 0 Root Port and UART2 nodes through graph port/endpoint. The M.2 Key E connector is powered by a 3.3V fixed regulator (vreg_wcn_3p3) which is sourced from the board's 12V DC input rail (vreg_dcin_12v). Both regulators are defined in this file. Also add the serial1 = &uart2 alias, which is required for the Bluetooth serdev device to be enumerated on the UART2 interface. The graph endpoint anchors (pcieport0_ep, uart2_ep) referenced here are defined in monaco.dtsi (see "arm64: dts: qcom: monaco: Add graph port/endpoint anchors to pcieport0 and uart2"). Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…8654AU PMM8654AU is a distinct PMIC variant from PMM8650AU despite sharing the same PMIC subtype. PMM8654AU implements additional registers added to the "hlos" register address spaces, so add qcom,pmm8654au-pon as a fallback to qcom,pmk8350-pon to distinguish it from the baseline PMK8350 PON implementation. Link: https://lore.kernel.org/all/20260724-b4-add_pwrkey_and_resin-v6-1-41acc214d93a@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
… inputs Add the Power On (PON) peripheral with power key and reset input support for the PMM8654AU PMIC on Monaco platforms. Link: https://lore.kernel.org/all/20260724-b4-add_pwrkey_and_resin-v6-3-41acc214d93a@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
…emory and SMMU mappings" This reverts commit cd0f5c6. Signed-off-by: Sairamreddy Bojja <sbojja@qti.qualcomm.com>
…nchors to board file of_graph_is_present() only checks for the presence of a 'port' child node, not whether remote-endpoint is actually connected. Adding empty port anchor nodes to monaco.dtsi caused hci_qca to enter the M.2 pwrseq probe path on all monaco-based boards, including qcs8300-ride which has a soldered WCN6855 and no M.2 Key E connector. This broke BT initialization on qcs8300-ride. Fix this by moving the port/endpoint nodes from monaco.dtsi into the monaco-evk.dts board file where the M.2 connector is actually present, so that of_graph_is_present() only returns true for boards that have an M.2 Key E connector described. Fixes: 2479c6b ("FROMLIST: arm64: dts: qcom: monaco: Add graph port/endpoint anchors to pcieport0 and uart2") Link: https://lore.kernel.org/all/20260819-b4-monaco-evk-m2-v1-v3-4-988145ef65cd@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…gulator" This reverts commit 32998bb in favour of the upstream fix, which is applied in the following patch. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
…CIe PHYs The QMP PCIe PHYs on QCS8300 require dedicated qref and refgen voltage supplies for stable operation. Without these supplies, the system may occasionally crash. Add vdda-qref-supply and vdda-refgen-supply in the board files (QCS8300-RIDE, Monaco-EVK and Monaco-Monza-SoM), and add refgen-supply in the SoC DTSI (monaco.dtsi) since refgen is an on-chip regulator shared across boards. The PHY driver votes for refgen3 directly as a workaround for a hardware issue where QREF actually depends on refgen3 rather than refgen2 as documented. Link: https://lore.kernel.org/all/20260810112735.1326807-4-ziyue.zhang@oss.qualcomm.com/ Fixes: 33967ea ("arm64: dts: qcom: qcs8300-ride: enable pcie0 interface") Fixes: cdb613a ("arm64: dts: qcom: qcs8300-ride: enable pcie1 interface") Fixes: 41e2424 ("arm64: dts: qcom: monaco-evk: Enable PCIe0 and PCIe1.") Fixes: 5238f4e ("arm64: dts: qcom: Add Monaco Monza SoM") Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
… idle states Firmware supports both CPU power collapse (little/big_cpu_sleep_0) and CPU PLL/rail power collapse (little/big_cpu_sleep_1) idle states. However, CPU power collapse modes are often not utilized in favor of performance, so remove the CPU power collapse modes for monaco, aligning with SM8350/SM8450/SM8550/SM8650. Rename little/big_cpu_sleep_1 as little/big_cpu_sleep_0 since it is now the only CPU idle state in use. Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com> Reviewed-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260522-ml_cpuidle-v1-1-fd311cf33fb4@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
qcomlnxci
requested review from
a team,
Amit Kucheria (idlethread),
Shivendra Pratap (quicAspratap) and
yijiyang
and removed request for
a team
September 3, 2026 05:23
smankad-oss
self-requested a review
September 3, 2026 05:35
Shiraz Hashim (shashim-quic)
dismissed
smankad-oss’s stale review
September 3, 2026 07:18
The merge-base changed after approval.
Shiraz Hashim (shashim-quic)
force-pushed
the
tech/all/dt/qcs8300
branch
from
September 3, 2026 07:18
fbca2cb to
432db4e
Compare
Contributor
Author
|
Closing this PR as upstream changes are already present on topic branch (came as part of rebase of topic branch) |
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
15 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.
Firmware supports both CPU power collapse (little/big_cpu_sleep_0) and CPU PLL/rail power collapse (little/big_cpu_sleep_1) idle states. However, CPU power collapse modes are often not utilized in favor of performance, so remove the CPU power collapse modes for monaco, aligning with SM8350/SM8450/SM8550/SM8650.
Rename little/big_cpu_sleep_1 as little/big_cpu_sleep_0 since it is now the only CPU idle state in use.
CRs-Fixed: 4654990
Reviewed-by: Maulik Shah maulik.shah@oss.qualcomm.com
Link: https://lore.kernel.org/r/20260522-ml_cpuidle-v1-1-fd311cf33fb4@oss.qualcomm.com