* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: Konrad Dybcio @ 2026-06-26 11:20 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-2-d999be0e04f7@outlook.com>
On 6/25/26 4:10 PM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add support to bring up the M0 core of the bluetooth subsystem found in
> the IPQ5018 SoC.
>
> The signed firmware loaded is authenticated by TrustZone. If successful,
> the M0 core boots the firmware and the peripheral is taken out of reset
> using a Secure Channel Manager call to TrustZone.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
Can this not fit inside the existing PAS driver?
Konrad
^ permalink raw reply
* [PATCH] ARM: dts: ti: Fix typos in comments
From: Vidhu Sarwal @ 2026-06-26 11:17 UTC (permalink / raw)
To: Bartosz Golaszewski, Tony Lindgren, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-omap,
linux-arm-kernel, devicetree, linux-kernel, skhan, Vidhu Sarwal
Fix comment typos found with codespell across DaVinci and OMAP
board files:
limitaion -> limitation
swithes -> switches
converstion -> conversion
differnet -> different
Signed-off-by: Vidhu Sarwal <vidhu.linux@gmail.com>
---
arch/arm/boot/dts/ti/davinci/da850-lcdk.dts | 2 +-
arch/arm/boot/dts/ti/omap/am3517-evm.dts | 2 +-
arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts | 2 +-
arch/arm/boot/dts/ti/omap/omap4-panda-es.dts | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts b/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
index 8390d71b000a..e70edd5274fe 100644
--- a/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
+++ b/arch/arm/boot/dts/ti/davinci/da850-lcdk.dts
@@ -366,7 +366,7 @@ nand@2000000,0 {
* to NAND block 1 (NAND block 0 is not used by default)".
* The same doc mentions that for ROM "Silicon Revision 2.1",
* "Updated NAND boot mode to offer boot from block 0 or block 1".
- * However the limitaion is left here by default for compatibility
+ * However the limitation is left here by default for compatibility
* with older silicon and because it needs new boot pin settings
* not possible in stock LCDK.
*/
diff --git a/arch/arm/boot/dts/ti/omap/am3517-evm.dts b/arch/arm/boot/dts/ti/omap/am3517-evm.dts
index 40f15da81043..a4357fa9f006 100644
--- a/arch/arm/boot/dts/ti/omap/am3517-evm.dts
+++ b/arch/arm/boot/dts/ti/omap/am3517-evm.dts
@@ -213,7 +213,7 @@ &i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins>;
clock-frequency = <400000>;
- /* User DIP swithes [1:8] / User LEDS [1:2] */
+ /* User DIP switches [1:8] / User LEDS [1:2] */
tca6416: gpio@21 {
compatible = "ti,tca6416";
reg = <0x21>;
diff --git a/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts b/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
index 43cf4ade950b..76bfb364777e 100644
--- a/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
+++ b/arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts
@@ -420,7 +420,7 @@ stmpe811@41 {
st,mod-12b = <1>; /* 12-bit ADC */
st,ref-sel = <0>; /* internal ADC reference */
st,adc-freq = <1>; /* 3.25 MHz ADC clock speed */
- st,sample-time = <4>; /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>; /* ADC conversion time: 80 clocks */
stmpe_adc {
compatible = "st,stmpe-adc";
diff --git a/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts b/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
index a933fe560834..70c609811d11 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/ti/omap/omap4-panda-es.dts
@@ -12,7 +12,7 @@ / {
compatible = "ti,omap4-panda-es", "ti,omap4-panda", "ti,omap4460", "ti,omap4430", "ti,omap4";
};
-/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
+/* Audio routing is different between PandaBoard4430 and PandaBoardES */
&sound {
ti,model = "PandaBoardES";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Xu Yang @ 2026-06-26 11:15 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-2-kernel@airkyi.com>
On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The HPD function of Type-C DP is implemented through
> drm_connector_oob_hotplug_event(). For embedded DP, it is required
> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>
> To describe the relationship between the DP controller and the Type-C
> port device, we usually using drm_bridge to build a bridge chain.
>
> Now several USB-C controller drivers have already implemented the DP
> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
> HPD bridge on USB-C connector port device.
>
> But this requires the USB-C controller driver to manually register the
> HPD bridge. If the driver does not implement this feature, the bridge
> will not be create.
>
> So this patch implements a generic DP HPD bridge based on
> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
> Type-C port device containing the DP svid is registered, it will
> create an HPD bridge for it without the need for the USB-C controller
> driver to implement it.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
>
> (no changes since v14)
>
> Changes in v13:
> - Only register drm dp hpd bridge for typec port altmode device.
>
> (no changes since v12)
>
> Changes in v11:
> - Switch to using typec bus notifiers.
>
> (no changes since v10)
>
> Changes in v9:
> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
> - Add more commit comment about problem background.
>
> Changes in v8:
> - Merge generic DP HPD bridge into one module.
> ---
>
> drivers/gpu/drm/bridge/Kconfig | 10 ++++
> drivers/gpu/drm/bridge/Makefile | 1 +
> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
> 3 files changed, 60 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a250afd8d662..559487aa09a9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
> Simple bridge that terminates the bridge chain and provides HPD
> support.
>
> +if DRM_AUX_HPD_BRIDGE
> +config DRM_AUX_HPD_TYPEC_BRIDGE
> + tristate
> + depends on TYPEC || !TYPEC
> + default TYPEC
> + help
> + Simple bridge that terminates the bridge chain and provides HPD
> + support. It build bridge on each USB-C connector device node.
> +endif
> +
Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
manually.
$ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 11:16 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB67364ADE8CDD7C31297AE18D9DEB2@SN7PR19MB6736.namprd19.prod.outlook.com>
On 26/06/2026 12:51, George Moussalem wrote:
>>
>> No supplies? no address space? How do you actually trigger remoteproc
>> startup?
>
> No supplied and no address space. The core is booted by a
> qcom_scm_auth_and_reset call to TrustZone which authenticated the
> firmware, takes it out of reset and boots it.
Then commit msg could be improved:
"Firmware loaded is authenticated via TrustZone." ->
"Firmware is loaded and authenticated via TrustZone."
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 3/3] arm64: dts: qcom: monaco-ac-evk: Add IFP mezzanine
From: Umang Chheda @ 2026-06-26 11:13 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, richardcochran
Cc: linux-arm-msm, devicetree, linux-kernel, umang.chheda, mohd.anwar,
krishna.chundru, monish.chunara
In-Reply-To: <20260626111301.3479559-1-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>
---
arch/arm64/boot/dts/qcom/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 90da4a3d4e33..97d8d5daba65 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -67,6 +67,9 @@ dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtb
monaco-evk-el2-dtbs := monaco-evk.dtb monaco-el2.dtbo
+monaco-ac-evk-ifp-mezzanine-dtbs := monaco-ac-evk.dtb monaco-evk-ifp-mezzanine.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-ac-evk-ifp-mezzanine.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-el2.dtb
monaco-evk-ifp-mezzanine-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/3] arm64: dts: qcom: monaco: Add monaco-ac EVK board
From: Umang Chheda @ 2026-06-26 11:13 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, richardcochran
Cc: linux-arm-msm, devicetree, linux-kernel, umang.chheda, mohd.anwar,
krishna.chundru, monish.chunara, Faruque Ansari
In-Reply-To: <20260626111301.3479559-1-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>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-ac-evk.dts | 938 +++++++++++++++++++++
2 files changed, 939 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..90da4a3d4e33 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -59,6 +59,7 @@ dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-nothing-asteroids.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-arduino-monza.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-ac-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
monaco-evk-camera-imx577-dtbs := monaco-evk.dtb monaco-evk-camera-imx577.dtbo
diff --git a/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts b/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
new file mode 100644
index 000000000000..6f3c3ffefe34
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
@@ -0,0 +1,938 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "monaco.dtsi"
+#include "monaco-pmics.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Monaco-ac EVK";
+ compatible = "qcom,monaco-evk", "qcom,qcs8300";
+
+ aliases {
+ ethernet0 = ðernet0;
+ i2c1 = &i2c1;
+ serial0 = &uart7;
+ serial2 = &uart6;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ connector-2 {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+
+ id-gpios = <&pmm8620au_0_gpios 9 GPIO_ACTIVE_HIGH>;
+ vbus-gpios = <&expander6 7 GPIO_ACTIVE_HIGH>;
+ vbus-supply = <&usb2_vbus>;
+
+ pinctrl-0 = <&usb2_id>;
+ pinctrl-names = "default";
+
+ port {
+ usb2_con_hs_ep: endpoint {
+ remote-endpoint = <&usb_2_dwc3_hs>;
+ };
+ };
+ };
+
+ dmic: audio-codec-0 {
+ compatible = "dmic-codec";
+ #sound-dai-cells = <0>;
+ num-channels = <1>;
+ };
+
+ max98357a: audio-codec-1 {
+ compatible = "maxim,max98357a";
+ #sound-dai-cells = <0>;
+ };
+
+ dp-connector-0 {
+ compatible = "dp-connector";
+ label = "DP0";
+ type = "mini";
+
+ port {
+ dp0_connector_in: endpoint {
+ remote-endpoint = <<8713sx_dp0_out>;
+ };
+ };
+ };
+
+ dp-connector-1 {
+ compatible = "dp-connector";
+ label = "DP1";
+ type = "mini";
+
+ port {
+ dp1_connector_in: endpoint {
+ remote-endpoint = <<8713sx_dp1_out>;
+ };
+ };
+ };
+
+ usb2_vbus: regulator-usb2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb2_vbus";
+ gpio = <&pmm8650au_1_gpios 7 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "qcom,qcs8275-sndcard";
+ model = "MONACO-EVK";
+
+ pinctrl-0 = <&hs0_mi2s_active>, <&mi2s1_active>;
+ pinctrl-names = "default";
+
+ hs0-mi2s-playback-dai-link {
+ link-name = "HS0 MI2S Playback";
+
+ codec {
+ sound-dai = <&max98357a>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ sec-mi2s-capture-dai-link {
+ link-name = "Secondary MI2S Capture";
+
+ codec {
+ sound-dai = <&dmic>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai SECONDARY_MI2S_TX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
+ vreg_cam0_2p8: vreg-cam0-2p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_cam0_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ startup-delay-us = <10000>;
+
+ gpio = <&tlmm 73 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam0_avdd_2v8_en_default>;
+ pinctrl-names = "default";
+ };
+
+ vreg_cam1_2p8: vreg-cam1-2p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_cam1_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ startup-delay-us = <10000>;
+
+ gpio = <&tlmm 74 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam1_avdd_2v8_en_default>;
+ pinctrl-names = "default";
+ };
+
+ vreg_cam2_2p8: vreg-cam2-2p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_cam2_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ startup-delay-us = <10000>;
+
+ gpio = <&tlmm 75 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam2_avdd_2v8_en_default>;
+ pinctrl-names = "default";
+ };
+
+ /* This comes from a PMIC handled within the SAIL domain */
+ vreg_s2s: vreg-s2s {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s2s";
+
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l3a: ldo3 {
+ regulator-name = "vreg_l3a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4a: ldo4 {
+ regulator-name = "vreg_l4a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5a: ldo5 {
+ regulator-name = "vreg_l5a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6a: ldo6 {
+ regulator-name = "vreg_l6a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7a: ldo7 {
+ regulator-name = "vreg_l7a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8a: ldo8 {
+ regulator-name = "vreg_l8a";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9a: ldo9 {
+ regulator-name = "vreg_l9a";
+ regulator-min-microvolt = <2970000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ vreg_s4a: smps4 {
+ regulator-name = "vreg_s4a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9a: smps9 {
+ regulator-name = "vreg_s9a";
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vreg_s5c: smps5 {
+ regulator-name = "vreg_s5c";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1c: ldo1 {
+ regulator-name = "vreg_l1c";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <512000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c: ldo2 {
+ regulator-name = "vreg_l2c";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c: ldo4 {
+ regulator-name = "vreg_l4c";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c: ldo7 {
+ regulator-name = "vreg_l7c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c: ldo8 {
+ regulator-name = "vreg_l8c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c: ldo9 {
+ regulator-name = "vreg_l9c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+ðernet0 {
+ phy-mode = "2500base-x";
+ phy-handle = <&hsgmii_phy0>;
+
+ pinctrl-0 = <ðernet0_default>;
+ pinctrl-names = "default";
+
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ nvmem-cells = <&mac_addr0>;
+ nvmem-cell-names = "mac-address";
+
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hsgmii_phy0: ethernet-phy@1c {
+ compatible = "ethernet-phy-id004d.d101";
+ reg = <0x1c>;
+ reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/qcs8300/a623_zap.mbn";
+};
+
+&i2c0 {
+ status = "okay";
+
+ bridge@4f {
+ compatible = "lontium,lt8713sx";
+ reg = <0x4f>;
+ reset-gpios = <&expander5 6 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt8713sx_dp_in: endpoint {
+ remote-endpoint = <&mdss_dp0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt8713sx_dp0_out: endpoint {
+ remote-endpoint = <&dp0_connector_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ lt8713sx_dp1_out: endpoint {
+ remote-endpoint = <&dp1_connector_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ pinctrl-0 = <&qup_i2c1_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ pagesize = <64>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac_addr0: mac-addr@0 {
+ reg = <0x0 0x6>;
+ };
+ };
+ };
+};
+
+&i2c15 {
+ pinctrl-0 = <&qup_i2c15_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ expander0: gpio@38 {
+ compatible = "ti,tca9538";
+ reg = <0x38>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 56 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander0_int>;
+ pinctrl-names = "default";
+ };
+
+ expander1: gpio@39 {
+ compatible = "ti,tca9538";
+ reg = <0x39>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 16 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander1_int>;
+ pinctrl-names = "default";
+ };
+
+ expander2: gpio@3a {
+ compatible = "ti,tca9538";
+ reg = <0x3a>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 95 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander2_int>;
+ pinctrl-names = "default";
+ };
+
+ expander3: gpio@3b {
+ compatible = "ti,tca9538";
+ reg = <0x3b>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 24 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander3_int>;
+ pinctrl-names = "default";
+ };
+
+ expander4: gpio@3c {
+ compatible = "ti,tca9538";
+ reg = <0x3c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 96 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander4_int>;
+ pinctrl-names = "default";
+ };
+
+ expander5: gpio@3d {
+ compatible = "ti,tca9538";
+ reg = <0x3d>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander5_int>;
+ pinctrl-names = "default";
+ };
+
+ expander6: gpio@3e {
+ compatible = "ti,tca9538";
+ reg = <0x3e>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 52 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander6_int>;
+ pinctrl-names = "default";
+ };
+};
+
+&iris {
+ status = "okay";
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp0 {
+ pinctrl-0 = <&dp_hot_plug_det>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&mdss_dp0_out {
+ data-lanes = <0 1 2 3>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+ remote-endpoint = <<8713sx_dp_in>;
+};
+
+&mdss_dp0_phy {
+ vdda-phy-supply = <&vreg_l5a>;
+ vdda-pll-supply = <&vreg_l4a>;
+
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pcie1_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcieport0 {
+ reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+};
+
+&pcieport1 {
+ reset-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+};
+
+&pmm8620au_0_gpios {
+ usb2_id: usb2-id-state {
+ pins = "gpio9";
+ function = "normal";
+ input-enable;
+ bias-pull-up;
+ power-source = <0>;
+ };
+};
+
+&qup_i2c0_data_clk {
+ drive-strength = <2>;
+ bias-pull-up;
+};
+
+&qupv3_id_0 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs8300/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs8300/cdsp0.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_gpdsp {
+ firmware-name = "qcom/qcs8300/gpdsp0.mbn";
+
+ status = "okay";
+};
+
+&sdhc_1 {
+ vmmc-supply = <&vreg_l8a>;
+ vqmmc-supply = <&vreg_s2s>;
+
+ no-sd;
+ no-sdio;
+ non-removable;
+
+ status = "okay";
+};
+
+&serdes0 {
+ phy-supply = <&vreg_l4a>;
+
+ status = "okay";
+};
+
+&spi10 {
+ status = "okay";
+
+ tpm@0 {
+ compatible = "st,st33htpm-spi", "tcg,tpm_tis-spi";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&tlmm {
+ pcie0_default_state: pcie0-default-state {
+ wake-pins {
+ pins = "gpio0";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio1";
+ function = "pcie0_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio2";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ ethernet0_default: ethernet0-default-state {
+ ethernet0_mdc: ethernet0-mdc-pins {
+ pins = "gpio5";
+ function = "emac0_mdc";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+
+ ethernet0_mdio: ethernet0-mdio-pins {
+ pins = "gpio6";
+ function = "emac0_mdio";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+ };
+
+ expander5_int: expander5-int-state {
+ pins = "gpio3";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander1_int: expander1-int-state {
+ pins = "gpio16";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ qup_i2c1_default: qup-i2c1-state {
+ pins = "gpio19", "gpio20";
+ function = "qup0_se1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ pcie1_default_state: pcie1-default-state {
+ wake-pins {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio22";
+ function = "pcie1_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio23";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ expander3_int: expander3-int-state {
+ pins = "gpio24";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander6_int: expander6-int-state {
+ pins = "gpio52";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander0_int: expander0-int-state {
+ pins = "gpio56";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ cam0_avdd_2v8_en_default: cam0-avdd-2v8-en-state {
+ pins = "gpio73";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam1_avdd_2v8_en_default: cam1-avdd-2v8-en-state {
+ pins = "gpio74";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam2_avdd_2v8_en_default: cam2-avdd-2v8-en-state {
+ pins = "gpio75";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ qup_i2c15_default: qup-i2c15-state {
+ pins = "gpio91", "gpio92";
+ function = "qup1_se7";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ expander2_int: expander2-int-state {
+ pins = "gpio95";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander4_int: expander4-int-state {
+ pins = "gpio96";
+ function = "gpio";
+ bias-pull-up;
+ };
+};
+
+&uart6 {
+ status = "okay";
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l8a>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l4c>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l4a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l7c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
+
+&usb_qmpphy {
+ vdda-phy-supply = <&vreg_l7a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&usb_2 {
+ status = "okay";
+};
+
+&usb_2_dwc3_hs {
+ remote-endpoint = <&usb2_con_hs_ep>;
+};
+
+&usb_2_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l7c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: arm: qcom: Add monaco-ac-evk support
From: Umang Chheda @ 2026-06-26 11:12 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, richardcochran
Cc: linux-arm-msm, devicetree, linux-kernel, umang.chheda, mohd.anwar,
krishna.chundru, monish.chunara, Krzysztof Kozlowski
In-Reply-To: <20260626111301.3479559-1-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>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..0624560643e5 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -932,6 +932,7 @@ properties:
- items:
- enum:
- arduino,monza
+ - qcom,monaco-ac-evk
- qcom,monaco-evk
- qcom,qcs8300-ride
- const: qcom,qcs8300
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] arm64: dts: qcom: Introduce support for Monaco-ac-sku Evaluation Kit
From: Umang Chheda @ 2026-06-26 11:12 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, richardcochran
Cc: linux-arm-msm, devicetree, linux-kernel, umang.chheda, mohd.anwar,
krishna.chundru, monish.chunara
Add support for Qualcomm's Monaco-ac-sku 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-sku 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-ac delivers 20 TOPS of NPU performance vs 40 TOPS on
monaco-aa variant.
- The power delivery network is simplified from a 4-PMIC arrangement
(2x PM8654AU + Maxim MAX20018 + TI TPS6594) to 2 PMICs(2x PM8654AU)
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.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
Changes in v5:
- Create a seperate board DT file for this platform instead of having a
common DTSI file b/w monaco-evk and monaco-ac-evk platform - Dmitry.
- Link to v4: https://lore.kernel.org/lkml/20260427170505.1494703-1-umang.chheda@oss.qualcomm.com/
Changes in v4:
- Add support for combined DTB "monaco-ac-evk-ifp-mezzanine" which
overlays monaco-evk-ifp-mezzanine DTBO on top of monaco-ac-evk DT.
- Link to v3: https://lore.kernel.org/lkml/20260413114819.3894307-1-umang.chheda@oss.qualcomm.com/
Changes in v3:
- Extract common nodes of monaco-evk and monaco-ac-evk into and common
dtsi file "monaco-evk-common.dtsi" to avoid duplication - Dmitry.
- Update the commit text and cover letter to justify the re-factoring of
DT.
- Link to v2: https://lore.kernel.org/lkml/20260401-monaco-evk-ac-sku-v2-0-27b5f702cfba@oss.qualcomm.com/
Changes in v2:
- Drop keyword "sku" from the compatible string of board bindings
- Krzysztof.
- Wrap commit text of dt-bindings change based on upstream guidelines
- Krzysztof.
- Link to v1: https://patch.msgid.link/20260328-monaco-evk-ac-sku-v1-0-79d166fa5571@oss.qualcomm.com
Umang Chheda (2):
dt-bindings: arm: qcom: Add monaco-ac-evk support
arm64: dts: qcom: monaco: Add monaco-ac EVK board
.../devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-ac-evk.dts | 938 ++++++++++++++++++
3 files changed, 940 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
--
2.34.1
^ permalink raw reply
* Re: [PATCH 2/2] arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
From: sashiko-bot @ 2026-06-26 11:10 UTC (permalink / raw)
To: Jiqi Li; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260626105625.600156-3-lijq9@lenovo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree erroneously disables the QSPI NOR flash controller (`spi@3270000`), breaking OS-level access to the SOM's boot firmware.
--
commit 0ad71e09cd3382aee8aca7f31b76da55ec8f3499
Author: Jiqi Li <lijq9@lenovo.com>
arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
This commit adds a standalone device tree file for the Lenovo ThinkEdge
SE70 carrier board, which is based on the NVIDIA Tegra194 Xavier NX SOM.
It configures the 40-pin header pinmux, an external SD card slot, and
disables unused PWM and SPI nodes to reflect the passively cooled platform.
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
[ ... ]
> + pwm@32f0000 {
> + status = "disabled";
> + };
> +
> + spi@3270000 {
> + status = "disabled";
> + };
[Severity: Medium]
Will disabling spi@3270000 break OS-level access to the SOM's boot firmware?
This overrides the 'okay' status inherited from the carrier board DTSI,
disabling the QSPI controller needed to access the internal SPI NOR flash.
Without this controller, userspace tools may be permanently prevented from
updating the bootloader or firmware.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626105625.600156-1-lijq9@lenovo.com?part=2
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
From: Krzysztof Kozlowski @ 2026-06-26 10:58 UTC (permalink / raw)
To: Christian Marangi
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Ryder Lee, Michael Turquette,
Stephen Boyd, Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Jianjun Wang, linux-pci, devicetree,
linux-kernel, linux-mediatek, linux-clk, linux-arm-kernel
In-Reply-To: <20260625215741.3253212-2-ansuelsmth@gmail.com>
On Thu, Jun 25, 2026 at 11:57:34PM +0200, Christian Marangi wrote:
> Add additional reset to control PCIe PERSTOUT reset line for each of the 3
> PCIe lines.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> include/dt-bindings/reset/airoha,en7581-reset.h | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 19/19] MAINTAINERS: add Rambus CryptoManager Hub (CMH)
From: Krzysztof Kozlowski @ 2026-06-26 10:57 UTC (permalink / raw)
To: Saravanakrishnan Krishnamoorthy
Cc: Albert Ou, Alex Ousherovitch, Conor Dooley, David S. Miller,
Herbert Xu, Jonathan Corbet, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Shuah Khan, Alexandre Ghiti,
devicetree, Joel Wittenauer, linux-api, linux-crypto, linux-doc,
linux-kernel, linux-kselftest, linux-riscv, Shuah Khan,
sipsupport, Thi Nguyen
In-Reply-To: <20260625173328.1140487-20-skrishnamoorthy@rambus.com>
On Thu, Jun 25, 2026 at 10:33:27AM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch@rambus.com>
>
> Add MAINTAINERS entry for the CRI CryptoManager Hub (CMH) hardware
> crypto accelerator driver under drivers/crypto/cmh/.
>
> Co-developed-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> Signed-off-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> Signed-off-by: Alex Ousherovitch <aousherovitch@rambus.com>
> Reviewed-by: Joel Wittenauer <Joel.Wittenauer@cryptography.com>
> Reviewed-by: Thi Nguyen <thin@rambus.com>
Are these people really provided you with Reviewer's statement of
oversight? Do they understand what does it mean?
> ---
> MAINTAINERS | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 90034eb7874e..ecb389795e3d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6797,6 +6797,25 @@ F: kernel/cred.c
> F: rust/kernel/cred.rs
> F: Documentation/security/credentials.rst
>
> +CRI CRYPTOMANAGER HUB (CMH) HARDWARE CRYPTO ACCELERATOR
> +M: Alex Ousherovitch <aousherovitch@rambus.com>
> +M: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> +R: Joel Wittenauer <Joel.Wittenauer@cryptography.com>
> +R: Thi Nguyen <thin@rambus.com>
> +L: linux-crypto@vger.kernel.org
> +L: sipsupport@rambus.com (moderated for non-subscribers)
NAK, drop. You are not allowed to add here internal moderated mailing
lists. We are not going to participate in your corporate dances.
> +S: Maintained
> +T: git https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
Drop, you do not have commit rights there.
> +F: Documentation/ABI/testing/cmh-mgmt
> +F: Documentation/ABI/testing/debugfs-driver-cmh
> +F: Documentation/ABI/testing/sysfs-driver-cmh
> +F: Documentation/crypto/device_drivers/cmh.rst
> +F: Documentation/devicetree/bindings/crypto/cri,cmh.yaml
> +F: Documentation/userspace-api/ioctl/cmh_mgmt.rst
> +F: drivers/crypto/cmh/
> +F: include/uapi/linux/cmh_mgmt_ioctl.h
> +F: tools/testing/selftests/drivers/crypto/cmh/
> +
> INTEL CRPS COMMON REDUNDANT PSU DRIVER
> M: Ninad Palsule <ninad@linux.ibm.com>
> L: linux-hwmon@vger.kernel.org
> --
> 2.43.7
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Heh, I should have ignored your message...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
From: Jiqi Li @ 2026-06-26 10:56 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
In-Reply-To: <20260626105625.600156-1-lijq9@lenovo.com>
ThinkEdge SE70 is a fanless industrial edge gateway built around
NVIDIA Tegra194 Xavier NX SOM. This patch adds a standalone device
tree file describing core carrier board peripherals:
- Custom 40-pin header pinmux configuration
- External SD card slot with dedicated 3.3V fixed regulator
No fan, PWM, tachometer, extra camera/spi peripherals are present
on this passively cooled platform, so unused nodes are explicitly
disabled following mainline device tree best practices.
Static verification passed: dt_binding_check and dtbs compilation
complete without errors.
Signed-off-by: Jiqi Li <lijq9@lenovo.com>
---
arch/arm64/boot/dts/nvidia/Makefile | 1 +
.../nvidia/tegra194-lenovo-thinkedge-se70.dts | 129 ++++++++++++++++++
2 files changed, 130 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index 72c0cb5efa47..736a3f8a923f 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-p3509-0000+p3636-0001.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p2972-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p3509-0000+p3668-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p3509-0000+p3668-0001.dtb
+dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-lenovo-thinkedge-se70.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-sim-vdk.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0008.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
new file mode 100644
index 000000000000..47b770170507
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra194-p3668-0001.dtsi"
+#include "tegra194-p3509-0000.dtsi"
+
+/ {
+ model = "Lenovo ThinkEdge SE70";
+ compatible = "lenovo,thinkedge-se70", "nvidia,p3509-0000+p3668-0001", "nvidia,tegra194";
+
+ chosen {
+ bootargs = "console=ttyTCU0,115200";
+ };
+
+ /* Fixed 3.3V regulator for external SD card slot */
+ vdd_3v3_sd: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio TEGRA194_MAIN_GPIO(Q, 5) GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ enable-active-high;
+ status = "okay";
+ };
+
+ bus@0 {
+
+ /* Custom pinmux configurations for 40-pin expansion header */
+ pinmux@2430000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinmux_hdr40>;
+
+ pinmux_hdr40: pinmux-hdr40 {
+ pin7 {
+ nvidia,pins = "aud_mclk_ps4";
+ nvidia,function = "aud";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ pin11 {
+ nvidia,pins = "uart1_rts_pr4";
+ nvidia,function = "uarta";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ pin12 {
+ nvidia,pins = "dap5_sclk_pt5";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin35 {
+ nvidia,pins = "dap5_fs_pu0";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin36 {
+ nvidia,pins = "uart1_cts_pr5";
+ nvidia,function = "uarta";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin38 {
+ nvidia,pins = "dap5_din_pt7";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin40 {
+ nvidia,pins = "dap5_dout_pt6";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ };
+ };
+
+ /* Configure i2c bus clock to 400kHz for carrier board peripherals */
+ i2c@3160000 {
+ clock-frequency = <400000>;
+ status = "okay";
+ };
+
+ /* SDMMC3 for external user SD card slot with dedicated 3.3V power */
+ mmc@3440000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio_aon TEGRA194_AON_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
+ disable-wp;
+ no-1-8-v;
+ vmmc-supply = <&vdd_3v3_sd>;
+ status = "okay";
+ };
+
+ pwm@c340000 {
+ status = "disabled";
+ };
+ pwm@3280000 {
+ status = "disabled";
+ };
+ pwm@32c0000 {
+ status = "disabled";
+ };
+ pwm@32d0000 {
+ status = "disabled";
+ };
+ pwm@32f0000 {
+ status = "disabled";
+ };
+
+ spi@3270000 {
+ status = "disabled";
+ };
+ };
+
+ /* Disable fan hardware not populated on SE70 carrier board */
+ pwm-fan {
+ status = "disabled";
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
From: Jiqi Li @ 2026-06-26 10:56 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
In-Reply-To: <20260626105625.600156-1-lijq9@lenovo.com>
Lenovo ThinkEdge SE70 is a fanless industrial edge gateway carrier
board based on NVIDIA Tegra194 (Xavier NX) SOM.
Add the corresponding compatible string for device tree validation.
Signed-off-by: Jiqi Li <lijq9@lenovo.com>
---
Documentation/devicetree/bindings/arm/tegra.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 033a63f6c068..1a71b4195114 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -268,6 +268,11 @@ properties:
items:
- const: nvidia,p3509-0000+p3668-0001
- const: nvidia,tegra194
+ - description: Lenovo ThinkEdge SE70
+ items:
+ - const: lenovo,thinkedge-se70
+ - const: nvidia,p3509-0000+p3668-0001
+ - const: nvidia,tegra194
- items:
- const: nvidia,tegra234-vdk
- const: nvidia,tegra234
--
2.43.0
^ permalink raw reply related
* [RFC v4 PATCH 0/2] Add Lenovo ThinkEdge SE70 carrier board support
From: Jiqi Li @ 2026-06-26 10:56 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
This patch set introduces device tree binding and standalone DTS file
for Lenovo ThinkEdge SE70, a fanless industrial edge gateway powered by
NVIDIA Tegra194 (Xavier NX P3509-0000 + P3668-0001) SOM.
Patch 1 updates tegra.yaml bindings to add three-stage compatible string
matching board + SOM + SoC, aligning with existing Tegra carrier board specs.
Patch 2 adds a fully compliant carrier board DTS implementing 40-pin header
pinmux configuration, 400kHz I2C bus, and dedicated 3.3V SD-card regulator.
It also disables unpopulated PWM, fan, and SPI peripherals according to the
real hardware layout.
All static device tree checks pass: dtbs compile and dt_binding_check
complete without local errors. Pre-existing upstream DTSI warnings are
inherited and unrelated to this board addition.
We maintain internal downstream DTS for mass-production SE70 hardware.
Upstreaming follows the same OEM contribution pattern as other Tegra
carrier boards from Google and Xiaomi, reducing long-term out-of-tree
maintenance burden. This industrial platform has a 7-year production
lifecycle until 2028, and Lenovo will continuously backport DT fixes
during its service window. All peripherals use generic mainline drivers
with no proprietary extensions.
Changes in v4:
- Fix pinctrl subnode naming to comply with tegra194 pinmux schema regex rules
- Rework SD regulator implementation: remove invalid simple-bus wrapper,
adopt official NVIDIA P3668 regulator naming and add regulator-boot-on
- Fully comply with MMC binding requirements by adding bus-width = <4>,
disable-wp, and no-1-8-v properties to SDMMC3 node
- Add explicit spi@3270000 disable override to align with commit description
- Resolve all remaining Sashiko medium/high static DT violations
Jiqi Li (2):
dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
.../devicetree/bindings/arm/tegra.yaml | 5 +
arch/arm64/boot/dts/nvidia/Makefile | 1 +
.../nvidia/tegra194-lenovo-thinkedge-se70.dts | 129 ++++++++++++++++++
3 files changed, 135 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
--
2.43.0
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
From: Krzysztof Kozlowski @ 2026-06-26 10:55 UTC (permalink / raw)
To: Saravanakrishnan Krishnamoorthy
Cc: Albert Ou, Alex Ousherovitch, Conor Dooley, David S. Miller,
Herbert Xu, Jonathan Corbet, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Shuah Khan, Alexandre Ghiti,
devicetree, Joel Wittenauer, linux-api, linux-crypto, linux-doc,
linux-kernel, linux-kselftest, linux-riscv, Shuah Khan,
sipsupport, Thi Nguyen
In-Reply-To: <20260625173328.1140487-2-skrishnamoorthy@rambus.com>
On Thu, Jun 25, 2026 at 10:33:09AM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch@rambus.com>
>
> Add device tree binding schema for the CRI CryptoManager Hub (CMH)
> hardware crypto accelerator. The binding covers the parent SoC-level
> node with register region, interrupt, DMA properties, and per-core
> child nodes identified by compatible string and unit address.
...
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
OK, we are done. I am removing your posting from Patchwork.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-26 10:53 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-4-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
> Document the Qualcomm IPQ5018 Bluetooth controller.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> new file mode 100644
> index 000000000000..afd33f851858
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,ipq5018-bt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm IPQ5018 Bluetooth
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-bt
> +
> + interrupts:
> + items:
> + - description:
> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
What is M0?
Anyway, this part feels completely redundant. Can "interrupts" property
be anything else than an interrupt line from the device to the host
processor?
> + to notify it of events such as re
This feels useful, but cut/incomplete.
> +
> + qcom,ipc:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to a syscon node representing the APCS registers
> + - description: u32 representing offset to the register within the syscon
> + - description: u32 representing the ipc bit within the register
> + description: |
> + These entries specify the outgoing IPC bit used for signaling the remote
> + M0 BTSS core of a host event or for sending an ACK if the remote processor
> + expects it.
> +
> + qcom,rproc:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the remote processor node representing the M0 BTSS core.
> +
> +required:
> + - compatible
> + - interrupts
> + - qcom,ipc
> + - qcom,rproc
> +
> +allOf:
> + - $ref: bluetooth-controller.yaml#
> + - $ref: qcom,bluetooth-common.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + bluetooth: bluetooth {
Drop unused label
> + compatible = "qcom,ipq5018-bt";
> +
> + qcom,ipc = <&apcs_glb 8 23>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
No firmware to load?
It feels like remoteproc node split is fake. The property qcom,rproc is
even more supporting that case. Shouldn't this be simply one device -
bluetooth? What sort of two devices do you have exactly? How can I
identify them in the hardware?
> +
> + qcom,rproc = <&m0_btss>;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex5: update channel interrupts for gmac1 and gmac2
From: Dinh Nguyen @ 2026-06-26 10:53 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260626043146.961401F000E9@smtp.kernel.org>
On 6/25/26 23:31, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Incomplete DT update: gmac0 is left with an invalid interrupt count that will fail dtbs validation.
> --
>
> commit ce31f4c657e3508e9aef68e6da54a09c1d243026
> Author: Dinh Nguyen <dinguyen@kernel.org>
>
> arm64: dts: socfpga: agilex5: update channel interrupts for gmac1 and gmac2
>
> Populate the gmac1 and gmac2 interrupt list to support 8 TX/RX queue
> pairs.
>
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> index 02e62d954e949..140e4bf9fb155 100644
>> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> @@ -670,8 +670,40 @@ gmac1: ethernet@10820000 {
>> compatible = "altr,socfpga-stmmac-agilex5",
>> "snps,dwxgmac-2.10";
>> reg = <0x10820000 0x3500>;
>
> [Severity: Medium]
> Should gmac0 also be updated to include 17 interrupts?
>
There was an earlier patch that updatee gmac0 to 17 interrupts:
https://lore.kernel.org/all/20260609131641.28476-1-muhammad.nazim.amirul.nazle.asmade@altera.com/
Dinh
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: George Moussalem @ 2026-06-26 10:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260626-tiny-warm-jerboa-3ba57a@quoll>
Hi Krzysztof,
On 6/26/26 14:47, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
>> Document the M0 Bluetooth Subsystem remote processor core found in the
>> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
>> The firmware running on the M0 core provides bluetooth functionality.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>> new file mode 100644
>> index 000000000000..397bb6815d71
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>
> Use compatible as filename.
understood, will update in v2.
>
>> @@ -0,0 +1,72 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm M0 BTSS Peripheral Image Loader
>> +
>> +maintainers:
>> + - George Moussalem <george.moussalem@outlook.com>
>> +
>> +description:
>> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
>> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,ipq5018-btss-pil
>> +
>> + firmware-name:
>> + maxItems: 1
>> + description: Firmware name for the M0 Bluetooth Subsystem core
>
> You can drop description, pretty obvious.
will drop
>
>> +
>> + clocks:
>> + items:
>> + - description: M0 BTSS low power oscillator clock
>> +
>> + clock-names:
>> + items:
>> + - const: btss_lpo_clk
>
> Just "lpo"
will update
>
>> +
>> + memory-region:
>> + items:
>> + - description: M0 BTSS reserved memory carveout
>> +
>> + resets:
>> + items:
>> + - description: M0 BTSS reset
>> +
>> + reset-names:
>> + items:
>> + - const: btss_reset
>
> Drop names. Using block name as input name is not really useful.
Will drop
>
> No supplies? no address space? How do you actually trigger remoteproc
> startup?
No supplied and no address space. The core is booted by a
qcom_scm_auth_and_reset call to TrustZone which authenticated the
firmware, takes it out of reset and boots it.
>
>> +
>> +required:
>> + - compatible
>> + - firmware-name
>> + - clocks
>> + - clock-names
>> + - resets
>> + - reset-names
>> + - memory-region
>> +
>> +additionalProperties: false
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 10:47 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-1-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
> Document the M0 Bluetooth Subsystem remote processor core found in the
> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
> The firmware running on the M0 core provides bluetooth functionality.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
> new file mode 100644
> index 000000000000..397bb6815d71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
Use compatible as filename.
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm M0 BTSS Peripheral Image Loader
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +description:
> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-btss-pil
> +
> + firmware-name:
> + maxItems: 1
> + description: Firmware name for the M0 Bluetooth Subsystem core
You can drop description, pretty obvious.
> +
> + clocks:
> + items:
> + - description: M0 BTSS low power oscillator clock
> +
> + clock-names:
> + items:
> + - const: btss_lpo_clk
Just "lpo"
> +
> + memory-region:
> + items:
> + - description: M0 BTSS reserved memory carveout
> +
> + resets:
> + items:
> + - description: M0 BTSS reset
> +
> + reset-names:
> + items:
> + - const: btss_reset
Drop names. Using block name as input name is not really useful.
No supplies? no address space? How do you actually trigger remoteproc
startup?
> +
> +required:
> + - compatible
> + - firmware-name
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> + - memory-region
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V2 3/3] dmaengine: zynqmp_dma: Guard IRQ handler against spurious interrupts
From: Golla, Nagendra @ 2026-06-26 10:38 UTC (permalink / raw)
To: sashiko-reviews; +Cc: vkoul, Frank.Li, robh, dmaengine, conor+dt, devicetree
In-Reply-To: <20260618072615.5D3401F000E9@smtp.kernel.org>
On 6/18/2026 12:56 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> New issues:
> - [High] The interrupt handler drops valid interrupts when CONFIG_PM is disabled.
>
> Pre-existing issues:
> - [High] Memory and runtime PM reference leaks on error paths in zynqmp_dma_alloc_chan_resources().
> - [High] Missing synchronize_irq() before tasklet_kill() allows the tasklet to run after channel resources and PM references are freed.
> --
>
> commit 62db01b8d81ad56c8fb04b0d8f2adecdae634703
> Author: Golla Nagendra <nagendra.golla@amd.com>
>
> dmaengine: zynqmp_dma: Guard IRQ handler against spurious interrupts
>
> This commit adds a pm_runtime_get_if_active() check in the
> zynqmp_dma_irq_handler() to safely handle spurious interrupts. It
> returns IRQ_NONE immediately if the device is not runtime-active,
> preventing potential synchronous external aborts.
>
>> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
>> index a9dfec3c0ca3d..ce9163138be74 100644
>> --- a/drivers/dma/xilinx/zynqmp_dma.c
>> +++ b/drivers/dma/xilinx/zynqmp_dma.c
>> @@ -730,6 +730,9 @@ static irqreturn_t zynqmp_dma_irq_handler(int irq, void *data)
>> u32 isr, imr, status;
>> irqreturn_t ret = IRQ_NONE;
>>
>> + if (pm_runtime_get_if_active(chan->dev) <= 0)
>> + return IRQ_NONE;
>
> [Severity: High]
> When CONFIG_PM is disabled, the pm_runtime_get_if_active() inline stub
> automatically returns -EINVAL. Does this check unconditionally drop valid
> interrupts in non-PM configurations?
>
> Because -EINVAL is less than or equal to 0, the handler might always return
> IRQ_NONE. This could potentially lead to an unacknowledged interrupt storm
> or the kernel permanently disabling the IRQ line.
>
> [ ... ]
>
> [Severity: High]
> This isn't a bug introduced by this patch, but do the error paths in
> zynqmp_dma_alloc_chan_resources() leak the runtime PM reference?
>
> drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_alloc_chan_resources() {
> ...
> chan->sw_desc_pool = kzalloc_objs(*desc, ZYNQMP_DMA_NUM_DESCS);
> if (!chan->sw_desc_pool)
> return -ENOMEM;
> ...
> if (!chan->desc_pool_v)
> return -ENOMEM;
> ...
> }
>
> If pm_runtime_resume_and_get() is called earlier, returning directly
> on memory allocation failures without calling pm_runtime_put() will
> leak the PM reference and previously allocated memory.
>
>
> [Severity: High]
> This is a pre-existing issue, but does zynqmp_dma_synchronize() miss
> a required IRQ serialization step?
>
> drivers/dma/xilinx/zynqmp_dma.c:zynqmp_dma_synchronize() {
> struct zynqmp_dma_chan *chan = to_chan(dchan);
>
> tasklet_kill(&chan->tasklet);
> }
>
> If zynqmp_dma_irq_handler() is executing concurrently and gets preempted
> just before calling tasklet_schedule(), tasklet_kill() might see no
> scheduled tasklet and return immediately.
>
> When the IRQ handler resumes and schedules the tasklet, could it execute
> asynchronously after channel resources and PM references are freed,
> potentially causing a synchronous external abort?
>
> Would calling synchronize_irq() first resolve this?
Hi,
Thanks for catching, agreed and will fix in v3 along with other RCs from
the maintainers.
Thanks,
Nagendra>
^ permalink raw reply
* Re: [PATCH v4 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Andre Heider @ 2026-06-26 10:36 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree
In-Reply-To: <20260626-shadow-deps-v4-2-bba9831f2f1d@mailbox.org>
On 26.06.26 10:10 AM, Shuwei Wu wrote:
> Add CPU clock properties and OPP tables for the two CPU clusters in the
> SpacemiT K1 SoC. The OPP entries use voltage ranges because the CPU
> supply is shared by both clusters.
>
> Enable CPU DVFS on Banana Pi BPI-F3 by including the OPP tables and
> wiring the CPU nodes to the CPU regulator supply.
>
> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
With the musepi-pro dts enablement patch [0] on top, this is
Tested-by: Andre Heider <a.heider@gmail.com> # k1-musepi-pro
Works as advertised, I get two policies, matching the clusters:
$ cat /sys/devices/system/cpu/cpufreq/policy0/related_cpus
0 1 2 3
$ cat /sys/devices/system/cpu/cpufreq/policy4/related_cpus
4 5 6 7
Some time after boot:
$ cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
614400 31124
819000 185
1000000 158
1228800 341
1600000 1148
$ cat /sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
614400 29232
819000 198
1000000 212
1228800 443
1600000 3428
Creating one single-threaded load increases max freq time_in_state in one policy (4 here):
$ yes > /dev/null &
(...after some time)
$ cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
614400 45244
819000 187
1000000 169
1228800 345
1600000 1148
$ cat /sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
614400 38794
819000 201
1000000 226
1228800 450
1600000 7580
Creating load for all 8 cores in both:
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ yes > /dev/null &
$ cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
614400 51371
819000 190
1000000 171
1228800 352
1600000 4391
$ cat /sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
614400 44121
819000 203
1000000 244
1228800 452
1600000 11812
Thanks!
Andre
[0] https://lore.kernel.org/all/20260614122812.2287506-1-a.heider@gmail.com/
> ---
> Changes in v4:
> - Use separate OPP tables for the two CPU clock clusters
> - Use voltage ranges for the shared CPU supply
>
> Changes in v3:
> - Use one shared CPU OPP table for all CPUs
>
> Changes in v2:
> - Add k1-opp.dtsi with OPP tables for both CPU clusters
> - Assign CPU supplies and include OPP table for Banana Pi BPI-F3
> ---
> ---
> arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
> arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
> 3 files changed, 147 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> index 444c3b1e6f44..487179f7b9b9 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> @@ -4,6 +4,7 @@
> */
>
> #include "k1.dtsi"
> +#include "k1-opp.dtsi"
> #include "k1-pinctrl.dtsi"
>
> / {
> @@ -86,6 +87,38 @@ &combo_phy {
> status = "okay";
> };
>
> +&cpu_0 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_1 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_2 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_3 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_4 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_5 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_6 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> +&cpu_7 {
> + cpu-supply = <&buck1_0v9>;
> +};
> +
> &emmc {
> bus-width = <8>;
> mmc-hs400-1_8v;
> @@ -201,7 +234,7 @@ pmic@41 {
> dldoin2-supply = <&buck5>;
>
> regulators {
> - buck1 {
> + buck1_0v9: buck1 {
> regulator-min-microvolt = <500000>;
> regulator-max-microvolt = <3450000>;
> regulator-ramp-delay = <5000>;
> diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> new file mode 100644
> index 000000000000..4cebfcd87485
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/ {
> + cluster0_opp_table: opp-table-cluster0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-614400000 {
> + opp-hz = /bits/ 64 <614400000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-819000000 {
> + opp-hz = /bits/ 64 <819000000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1228800000 {
> + opp-hz = /bits/ 64 <1228800000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1600000000 {
> + opp-hz = /bits/ 64 <1600000000>;
> + opp-microvolt = <1050000 1050000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> + };
> +
> + cluster1_opp_table: opp-table-cluster1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-614400000 {
> + opp-hz = /bits/ 64 <614400000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-819000000 {
> + opp-hz = /bits/ 64 <819000000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1228800000 {
> + opp-hz = /bits/ 64 <1228800000>;
> + opp-microvolt = <950000 950000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> +
> + opp-1600000000 {
> + opp-hz = /bits/ 64 <1600000000>;
> + opp-microvolt = <1050000 1050000 1050000>;
> + clock-latency-ns = <200000>;
> + };
> + };
> +};
> +
> +&cpu_0 {
> + operating-points-v2 = <&cluster0_opp_table>;
> +};
> +
> +&cpu_1 {
> + operating-points-v2 = <&cluster0_opp_table>;
> +};
> +
> +&cpu_2 {
> + operating-points-v2 = <&cluster0_opp_table>;
> +};
> +
> +&cpu_3 {
> + operating-points-v2 = <&cluster0_opp_table>;
> +};
> +
> +&cpu_4 {
> + operating-points-v2 = <&cluster1_opp_table>;
> +};
> +
> +&cpu_5 {
> + operating-points-v2 = <&cluster1_opp_table>;
> +};
> +
> +&cpu_6 {
> + operating-points-v2 = <&cluster1_opp_table>;
> +};
> +
> +&cpu_7 {
> + operating-points-v2 = <&cluster1_opp_table>;
> +};
> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> index 529ec68e9c23..bdd109b81730 100644
> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> @@ -54,6 +54,7 @@ cpu_0: cpu@0 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <0>;
> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -84,6 +85,7 @@ cpu_1: cpu@1 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <1>;
> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -114,6 +116,7 @@ cpu_2: cpu@2 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <2>;
> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -144,6 +147,7 @@ cpu_3: cpu@3 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <3>;
> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -174,6 +178,7 @@ cpu_4: cpu@4 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <4>;
> + clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -204,6 +209,7 @@ cpu_5: cpu@5 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <5>;
> + clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -234,6 +240,7 @@ cpu_6: cpu@6 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <6>;
> + clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> @@ -264,6 +271,7 @@ cpu_7: cpu@7 {
> compatible = "spacemit,x60", "riscv";
> device_type = "cpu";
> reg = <7>;
> + clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> riscv,isa-base = "rv64i";
> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom: sort compatibles alphabetically by base SoC
From: Krzysztof Kozlowski @ 2026-06-26 10:31 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260625-reorg_qcom_binding-v1-1-f2c6501f7401@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 04:02:02PM +0530, Kathiravan Thirumoorthy wrote:
> The compatible entries in qcom.yaml were not in alphabetical order by
> their base SoC compatible string (the last const: qcom,* in each block),
> making the file harder to audit and maintain. Sort the entries for
> better maintenance.
>
> No functional change; reordering only.
>
> Assisted-by: Claude:claude-sonnet-4-6
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 490 ++++++++++++------------
> 1 file changed, 245 insertions(+), 245 deletions(-)
Well, close to churn affecting possible backporting, but OTOH this won't
get backported ever, so fine:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 10:30 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <065853f5-b11b-4316-814e-202f07acb6ea@oss.qualcomm.com>
Hi Jie,
On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:
[...]
> Hi Leo,
>
> To be honest, I would prefer not to modify the interconnect platform driver.
> On some Qualcomm platforms, multiple itnoc devices reside within small
> blocks(one or more than one for each block) and are connected to a dummy
> source. In such cases, two ATIDs are allocated for a path (the dummy source
> and the itnoc), which is inefficient. This is why the itnoc platform driver
> created to avoid this waste.
>
> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
> connected to multiple source and link devices, aggregating data from all
> source devices into a single output path.
As I said, it may be fragile to couple a specific device property (ATID)
to the AMBA driver.
You're now facing a case where a device cannot be registered as an AMBA
device, so it cannot use ATID. Likewise, I can imagine in future where a
device is registered as an AMBA device, but you don't want ATID.
> This device is implemented as an AMBA device but lacks proper hardware
> configuration. As a result, it must be handled in the driver as a
> workaround, which unfortunately breaks the original design intent.
Seems to me, it is not reasonable to pretend an AMBA device but AMBA
ID registers are absent.
How about add a new DT property ("qcom,tnoc-enable-atid") to force
enabling ATID?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: display: tegra: Add channel/syncpoint range properties
From: Krzysztof Kozlowski @ 2026-06-26 10:26 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <Np88My8kTE-rRphOw0a-Ew@nvidia.com>
On Thu, Jun 25, 2026 at 06:26:43PM +0900, Mikko Perttunen wrote:
> On Thursday, June 25, 2026 5:36 PM Krzysztof Kozlowski wrote:
> > On Mon, Jun 22, 2026 at 05:22:51PM +0900, Mikko Perttunen wrote:
> > > Channels and syncpoints available may be limited when other system
> >
> > What are channels and syncpoints?
>
> Very host1x-specific hardware resources. Somewhat close to GPU channels
> and semaphores / fences if you're familiar with those.
>
> >
> > > components are using them. Add properties nvidia,channels and
> > > nvidia,syncpoints to limit the range of usable channels and/or
> > > syncpoints.
> >
> > Why isn't this deducible from the compatible?
>
> When Host1x is partitioned, the hypervisor (or other software entity
> with access to the non-vm host1x register regions) can configure which
> channels and syncpoints are available to each partition arbitrarily.
So you will have different boards for the same SoC with different
values?
>
> How that partitioning was done is not discoverable through hardware
> directly, so we need to pass that information through device tree.
>
> >
> > Also, nvidia,channels is too broad/generic. This is not ADC, right? And
> > channels is a common term in IIO. And in few other cases.
>
> It's not ADC. Yes, it's a common term in a lot of contexts. I can call
> it nvidia,host1x-channels if you prefer but that seems a bit redundant
> given the context.
host1x is indeed poor, but maybe there is some way to be a bit more
descriptive? message-channels?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: tegra: Make non-vm registers optional
From: Krzysztof Kozlowski @ 2026-06-26 10:21 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <NWz2vh3HRYqBDySgTFAF_g@nvidia.com>
On Thu, Jun 25, 2026 at 06:17:39PM +0900, Mikko Perttunen wrote:
> On Thursday, June 25, 2026 5:34 PM Krzysztof Kozlowski wrote:
> > On Mon, Jun 22, 2026 at 05:22:50PM +0900, Mikko Perttunen wrote:
> > > Host1x can be used without accessing the hypervisor or common
> > > registers. Adjust the bindings to make them optional.
> >
> > You still have these registers in the hardware, so it is not optional,
> > not flexible. IOW, DTS represents the view of real hardware for the
> > software, and that hardware still has this address space regardless if
> > OS should use it or not.
> >
> > Otherwise you need to provide better background here.
> >
> > Best regards,
> > Krzysztof
> >
> >
>
> The intent is that the vm-only version is used in situations where the
> other register regions are not available to software. Typically that
> means running as a virtual machine, and the hypervisor owns the non-vm
> register regions and doesn't pass them to the guest.
>
> Since the guest runs under the hypervisor, its view of 'real hardware'
> is what the hypervisor is exposing to it -- in this case with just the
> "vm" register region.
>
> I'll add further explanation along above lines to the commit message
> if you're OK with it.
Yeah, it's fine. Please extend the commit msg to make it more obvious.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox