[PATCH v5 0/6] arm64: qcom: Add support for QCS9075 boards

[PATCH v5 0/6] arm64: qcom: Add support for QCS9075 boards

[Wasim Nazir]

This series:

Add support for Qualcomm's rb8, ride/ride-r3 boards using QCS9075 SoC.

QCS9075 is compatible IoT-industrial grade variant of SA8775p SoC.
Unlike QCS9100, it doesn't have safety monitoring feature of
Safety-Island(SAIL) subsystem, which affects thermal management.

In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
does corrective action for each subsystem based on sensor violation
to comply safety standards. But as QCS9075 is non-safe SoC it requires
conventional thermal mitigation for thermal management.

Difference between Ride & ride-r3 boards is ethernet phy,
ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.

This series depends on [1] for thermal functionality to work.

[1]: https://lore.kernel.org/all/20241112-sa8775p_cpuidle-v1-1-66ff3ba72464@quicinc.com/

---
Changelog:

v5:
  - Remove defconfig patch as the config is product specific.
  - v4: https://lore.kernel.org/all/20241217064856.2772305-1-quic_wasimn@quicinc.com/

v4:
  - Replace dts to dtsi in Ride/Ride-r3 platform files.
  - Add thermal patch to differentiate between 9100 vs 9075.
  - Add proper abbreviation and update commit for 9100 vs 9075.
  - v3: https://lore.kernel.org/all/20241119174954.1219002-1-quic_wasimn@quicinc.com/

v3:
  - Fix RB8 board compatible string.
  - v2: https://lore.kernel.org/all/20241115225152.3264396-1-quic_wasimn@quicinc.com/

v2:
  - Remove unused dp nodes & update commit for ride vs ride-r3.
  - v1: https://lore.kernel.org/all/20241110145339.3635437-1-quic_wasimn@quicinc.com/

Manaf Meethalavalappu Pallikunhi (1):
  arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

Wasim Nazir (5):
  dt-bindings: arm: qcom,ids: add SoC ID for QCS9075
  soc: qcom: socinfo: add QCS9075 SoC ID
  dt-bindings: arm: qcom: Document rb8/ride/ride-r3 on QCS9075
  arm64: dts: qcom: Add support for QCS9075 RB8
  arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

 .../devicetree/bindings/arm/qcom.yaml         |   9 +
 arch/arm64/boot/dts/qcom/Makefile             |   3 +
 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      | 282 +++++++++++++++++
 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |  47 +++
 arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |  47 +++
 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
 drivers/soc/qcom/socinfo.c                    |   1 +
 include/dt-bindings/arm/qcom,ids.h            |   1 +
 8 files changed, 677 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi


base-commit: 8155b4ef3466f0e289e8fcc9e6e62f3f4dceeac2
--
2.47.0

[PATCH v5 1/6] dt-bindings: arm: qcom,ids: add SoC ID for QCS9075

[Wasim Nazir]

Add the unique ID for Qualcomm QCS9075 SoC.
This value is used to differentiate the SoC across qcom targets.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
 include/dt-bindings/arm/qcom,ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h
index e850dc3a1ad3..1b3e0176dcb7 100644
--- a/include/dt-bindings/arm/qcom,ids.h
+++ b/include/dt-bindings/arm/qcom,ids.h
@@ -284,6 +284,7 @@
 #define QCOM_ID_QCS9100			667
 #define QCOM_ID_QCS8300			674
 #define QCOM_ID_QCS8275			675
+#define QCOM_ID_QCS9075			676
 #define QCOM_ID_QCS615			680

 /*
--
2.47.0

[PATCH v5 2/6] soc: qcom: socinfo: add QCS9075 SoC ID

[Wasim Nazir]

Update soc_id table for the Qualcomm QCS9075 SoC
to represent qcs9075 machine.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
 drivers/soc/qcom/socinfo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 62fadfe44a09..174210f3467b 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -451,6 +451,7 @@ static const struct soc_id soc_id[] = {
 	{ qcom_board_id(QCS9100) },
 	{ qcom_board_id(QCS8300) },
 	{ qcom_board_id(QCS8275) },
+	{ qcom_board_id(QCS9075) },
 	{ qcom_board_id(QCS615) },
 };

--
2.47.0

[PATCH v5 3/6] dt-bindings: arm: qcom: Document rb8/ride/ride-r3 on QCS9075

[Wasim Nazir]

qcs9075 rb8, ride & ride-r3 boards are based on QCS9075 SoC.

QCS9075 is compatible IoT-industrial grade variant of SA8775p SoC.
Unlike QCS9100, it doesn't have safety monitoring feature of
Safety-Island(SAIL) subsystem, which affects thermal management.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d394dffe3fba..8cee92a804c4 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -57,6 +57,7 @@ description: |
         qcs8550
         qcm2290
         qcm6490
+        qcs9075
         qcs9100
         qdu1000
         qrb2210
@@ -950,6 +951,14 @@ properties:
               - qcom,sa8775p-ride-r3
           - const: qcom,sa8775p

+      - items:
+          - enum:
+              - qcom,qcs9075-rb8
+              - qcom,qcs9075-ride
+              - qcom,qcs9075-ride-r3
+          - const: qcom,qcs9075
+          - const: qcom,sa8775p
+
       - items:
           - enum:
               - qcom,qcs9100-ride
--
2.47.0

[PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Wasim Nazir]

Add initial device tree support for the RB8 board
based on Qualcomm's QCS9075 SoC.

Basic changes are supported for boot to shell.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
 arch/arm64/boot/dts/qcom/Makefile        |   1 +
 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
 2 files changed, 282 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4686f2a8ddd8..78613a1bd34a 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -117,6 +117,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs615-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
new file mode 100644
index 000000000000..ecaa383b6508
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "sa8775p.dtsi"
+#include "sa8775p-pmics.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. Robotics RB8";
+	compatible = "qcom,qcs9075-rb8", "qcom,qcs9075", "qcom,sa8775p";
+
+	aliases {
+		serial0 = &uart10;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vreg_s4a: smps4 {
+			regulator-name = "vreg_s4a";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1816000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s5a: smps5 {
+			regulator-name = "vreg_s5a";
+			regulator-min-microvolt = <1850000>;
+			regulator-max-microvolt = <1996000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s9a: smps9 {
+			regulator-name = "vreg_s9a";
+			regulator-min-microvolt = <535000>;
+			regulator-max-microvolt = <1120000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4a: ldo4 {
+			regulator-name = "vreg_l4a";
+			regulator-min-microvolt = <788000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5a: ldo5 {
+			regulator-name = "vreg_l5a";
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6a: ldo6 {
+			regulator-name = "vreg_l6a";
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <970000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7a: ldo7 {
+			regulator-name = "vreg_l7a";
+			regulator-min-microvolt = <720000>;
+			regulator-max-microvolt = <950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8a: ldo8 {
+			regulator-name = "vreg_l8a";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9a: ldo9 {
+			regulator-name = "vreg_l9a";
+			regulator-min-microvolt = <2970000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vreg_l1c: ldo1 {
+			regulator-name = "vreg_l1c";
+			regulator-min-microvolt = <1140000>;
+			regulator-max-microvolt = <1260000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c: ldo2 {
+			regulator-name = "vreg_l2c";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c: ldo3 {
+			regulator-name = "vreg_l3c";
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   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>;
+			/*
+			 * FIXME: This should have regulator-allow-set-load but
+			 * we're getting an over-current fault from the PMIC
+			 * when switching to LPM.
+			 */
+		};
+
+		vreg_l5c: ldo5 {
+			regulator-name = "vreg_l5c";
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6c: ldo6 {
+			regulator-name = "vreg_l6c";
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <1980000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7c: ldo7 {
+			regulator-name = "vreg_l7c";
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8c: ldo8 {
+			regulator-name = "vreg_l8c";
+			regulator-min-microvolt = <2400000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9c: ldo9 {
+			regulator-name = "vreg_l9c";
+			regulator-min-microvolt = <1650000>;
+			regulator-max-microvolt = <2700000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vreg_s4e: smps4 {
+			regulator-name = "vreg_s4e";
+			regulator-min-microvolt = <970000>;
+			regulator-max-microvolt = <1520000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s7e: smps7 {
+			regulator-name = "vreg_s7e";
+			regulator-min-microvolt = <1010000>;
+			regulator-max-microvolt = <1170000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s9e: smps9 {
+			regulator-name = "vreg_s9e";
+			regulator-min-microvolt = <300000>;
+			regulator-max-microvolt = <570000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6e: ldo6 {
+			regulator-name = "vreg_l6e";
+			regulator-min-microvolt = <1280000>;
+			regulator-max-microvolt = <1450000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8e: ldo8 {
+			regulator-name = "vreg_l8e";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sleep_clk {
+	clock-frequency = <32768>;
+};
+
+&tlmm {
+	qup_uart10_default: qup-uart10-state {
+		pins = "gpio46", "gpio47";
+		function = "qup1_se3";
+	};
+};
+
+&uart10 {
+	compatible = "qcom,geni-debug-uart";
+	pinctrl-0 = <&qup_uart10_default>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&xo_board_clk {
+	clock-frequency = <38400000>;
+};
--
2.47.0

Re: [PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Dmitry Baryshkov]

On Sun, Dec 29, 2024 at 08:53:30PM +0530, Wasim Nazir wrote:
> Add initial device tree support for the RB8 board
> based on Qualcomm's QCS9075 SoC.
> 
> Basic changes are supported for boot to shell.
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile        |   1 +
>  arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
>  2 files changed, 282 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> 

For the next submission please include at least the UFS support. The
board is pretty useless without the actual storage support.

-- 
With best wishes
Dmitry

Re: [PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Wasim Nazir]

On Tue, May 06, 2025 at 03:08:17PM +0300, Dmitry Baryshkov wrote:
> On Sun, Dec 29, 2024 at 08:53:30PM +0530, Wasim Nazir wrote:
> > Add initial device tree support for the RB8 board
> > based on Qualcomm's QCS9075 SoC.
> > 
> > Basic changes are supported for boot to shell.
> > 
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > ---
> >  arch/arm64/boot/dts/qcom/Makefile        |   1 +
> >  arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
> >  2 files changed, 282 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> > 
> 
> For the next submission please include at least the UFS support. The
> board is pretty useless without the actual storage support.

We will be adding UFS change once the basic boot-to-shell changes are in
place.
I have already pushed the next submission (v6) here [1].

[1] https://lore.kernel.org/all/20250429054906.113317-1-quic_wasimn@quicinc.com/

> 
> -- 
> With best wishes
> Dmitry

Regards,
Wasim

Re: [PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Dmitry Baryshkov]

On 06/05/2025 15:29, Wasim Nazir wrote:
> On Tue, May 06, 2025 at 03:08:17PM +0300, Dmitry Baryshkov wrote:
>> On Sun, Dec 29, 2024 at 08:53:30PM +0530, Wasim Nazir wrote:
>>> Add initial device tree support for the RB8 board
>>> based on Qualcomm's QCS9075 SoC.
>>>
>>> Basic changes are supported for boot to shell.
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
>>> ---
>>>   arch/arm64/boot/dts/qcom/Makefile        |   1 +
>>>   arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
>>>   2 files changed, 282 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>>>
>>
>> For the next submission please include at least the UFS support. The
>> board is pretty useless without the actual storage support.
> 
> We will be adding UFS change once the basic boot-to-shell changes are in
> place.
> I have already pushed the next submission (v6) here [1].
> 
> [1] https://lore.kernel.org/all/20250429054906.113317-1-quic_wasimn@quicinc.com/

Sorry, I missed it because of the rename.

If v6 gets resent for whatever reason, please include UFS into v7.

> 
>>
>> -- 
>> With best wishes
>> Dmitry
> 
> Regards,
> Wasim


-- 
With best wishes
Dmitry

Re: [PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Wasim Nazir]

On Tue, May 06, 2025 at 03:30:43PM +0300, Dmitry Baryshkov wrote:
> On 06/05/2025 15:29, Wasim Nazir wrote:
> > On Tue, May 06, 2025 at 03:08:17PM +0300, Dmitry Baryshkov wrote:
> > > On Sun, Dec 29, 2024 at 08:53:30PM +0530, Wasim Nazir wrote:
> > > > Add initial device tree support for the RB8 board
> > > > based on Qualcomm's QCS9075 SoC.
> > > > 
> > > > Basic changes are supported for boot to shell.
> > > > 
> > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > ---
> > > >   arch/arm64/boot/dts/qcom/Makefile        |   1 +
> > > >   arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
> > > >   2 files changed, 282 insertions(+)
> > > >   create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> > > > 
> > > 
> > > For the next submission please include at least the UFS support. The
> > > board is pretty useless without the actual storage support.
> > 
> > We will be adding UFS change once the basic boot-to-shell changes are in
> > place.
> > I have already pushed the next submission (v6) here [1].
> > 
> > [1] https://lore.kernel.org/all/20250429054906.113317-1-quic_wasimn@quicinc.com/
> 
> Sorry, I missed it because of the rename.
> 
> If v6 gets resent for whatever reason, please include UFS into v7.

v6 is just split from v5 to separate out evk & ride changes.
Currently it only supports boot to shell so UFS change is not added.
UFS change will be added in incremental patch after boot to shell is
approved.

> 
> > 
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> > 
> > Regards,
> > Wasim
> 
> 
> -- 
> With best wishes
> Dmitry

Regards,
Wasim

Re: [PATCH v5 4/6] arm64: dts: qcom: Add support for QCS9075 RB8

[Konrad Dybcio]

On 5/6/25 3:14 PM, Wasim Nazir wrote:
> On Tue, May 06, 2025 at 03:30:43PM +0300, Dmitry Baryshkov wrote:
>> On 06/05/2025 15:29, Wasim Nazir wrote:
>>> On Tue, May 06, 2025 at 03:08:17PM +0300, Dmitry Baryshkov wrote:
>>>> On Sun, Dec 29, 2024 at 08:53:30PM +0530, Wasim Nazir wrote:
>>>>> Add initial device tree support for the RB8 board
>>>>> based on Qualcomm's QCS9075 SoC.
>>>>>
>>>>> Basic changes are supported for boot to shell.
>>>>>
>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
>>>>> ---
>>>>>   arch/arm64/boot/dts/qcom/Makefile        |   1 +
>>>>>   arch/arm64/boot/dts/qcom/qcs9075-rb8.dts | 281 +++++++++++++++++++++++
>>>>>   2 files changed, 282 insertions(+)
>>>>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>>>>>
>>>>
>>>> For the next submission please include at least the UFS support. The
>>>> board is pretty useless without the actual storage support.
>>>
>>> We will be adding UFS change once the basic boot-to-shell changes are in
>>> place.
>>> I have already pushed the next submission (v6) here [1].
>>>
>>> [1] https://lore.kernel.org/all/20250429054906.113317-1-quic_wasimn@quicinc.com/
>>
>> Sorry, I missed it because of the rename.
>>
>> If v6 gets resent for whatever reason, please include UFS into v7.
> 
> v6 is just split from v5 to separate out evk & ride changes.
> Currently it only supports boot to shell so UFS change is not added.
> UFS change will be added in incremental patch after boot to shell is
> approved.

Please take this as a general heuristic for the future - if a justified
change takes less time to perform than typing 3 emails to argue against
making it, it's not worth typing the emails

Konrad

[PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

Add device tree support for QCS9075 Ride & Ride-r3 boards.

QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
subsystem which is available in QCS9100, and it affects thermal
management.

Also, between ride and ride-r3 ethernet phy is different.
Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.

Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
 arch/arm64/boot/dts/qcom/Makefile            |  2 +
 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
 arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
 3 files changed, 94 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 78613a1bd34a..41cb2bbd3472 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
new file mode 100644
index 000000000000..d9a8956d3a76
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include "sa8775p-ride.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
+	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
+};
+
+&ethernet0 {
+	phy-mode = "2500base-x";
+};
+
+&ethernet1 {
+	phy-mode = "2500base-x";
+};
+
+&mdio {
+	compatible = "snps,dwmac-mdio";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	sgmii_phy0: phy@8 {
+		compatible = "ethernet-phy-id31c3.1c33";
+		reg = <0x8>;
+		device_type = "ethernet-phy";
+		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+		reset-assert-us = <11000>;
+		reset-deassert-us = <70000>;
+	};
+
+	sgmii_phy1: phy@0 {
+		compatible = "ethernet-phy-id31c3.1c33";
+		reg = <0x0>;
+		device_type = "ethernet-phy";
+		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+		reset-assert-us = <11000>;
+		reset-deassert-us = <70000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
new file mode 100644
index 000000000000..3b524359a72d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include "sa8775p-ride.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
+	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
+};
+
+&ethernet0 {
+	phy-mode = "sgmii";
+};
+
+&ethernet1 {
+	phy-mode = "sgmii";
+};
+
+&mdio {
+	compatible = "snps,dwmac-mdio";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	sgmii_phy0: phy@8 {
+		compatible = "ethernet-phy-id0141.0dd4";
+		reg = <0x8>;
+		device_type = "ethernet-phy";
+		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+		reset-assert-us = <11000>;
+		reset-deassert-us = <70000>;
+	};
+
+	sgmii_phy1: phy@a {
+		compatible = "ethernet-phy-id0141.0dd4";
+		reg = <0xa>;
+		device_type = "ethernet-phy";
+		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+		reset-assert-us = <11000>;
+		reset-deassert-us = <70000>;
+	};
+};
--
2.47.0

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Konrad Dybcio]

On 29.12.2024 4:23 PM, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
> 
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
> 
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> 
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---

+ Andrew

IIUC we have a similar case to

https://lore.kernel.org/linux-arm-msm/cbd696c0-3b25-438b-a279-a4263308323a@lunn.ch/

here in the first file changed, please see below and let me know if
the rest makes sense for the networking part

Konrad

>  arch/arm64/boot/dts/qcom/Makefile            |  2 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
>  3 files changed, 94 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@0 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x0>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "sgmii";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "sgmii";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@a {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0xa>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> --
> 2.47.0
> 

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Andrew Lunn]

> > +&ethernet0 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&ethernet1 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > +	compatible = "snps,dwmac-mdio";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	sgmii_phy0: phy@8 {
> > +		compatible = "ethernet-phy-id31c3.1c33";
> > +		reg = <0x8>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +
> > +	sgmii_phy1: phy@0 {

SGMII is 10/100/1000. You have a phy-mode of 2500base-x, which is only
2500. So calling this sgmii_phy is wrong. Just call it phy1: phy@0.

	Andrew

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Tue, Dec 31, 2024 at 06:10:15AM +0100, Andrew Lunn wrote:
> > > +&ethernet0 {
> > > +	phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&ethernet1 {
> > > +	phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&mdio {
> > > +	compatible = "snps,dwmac-mdio";
> > > +	#address-cells = <1>;
> > > +	#size-cells = <0>;
> > > +
> > > +	sgmii_phy0: phy@8 {
> > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > +		reg = <0x8>;
> > > +		device_type = "ethernet-phy";
> > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > +		reset-assert-us = <11000>;
> > > +		reset-deassert-us = <70000>;
> > > +	};
> > > +
> > > +	sgmii_phy1: phy@0 {
> 
> SGMII is 10/100/1000. You have a phy-mode of 2500base-x, which is only
> 2500. So calling this sgmii_phy is wrong. Just call it phy1: phy@0.
> 

Thanks Konrad/Andrew will fix this in next patch.

Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Dmitry Baryshkov]

On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
> 
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
> 
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.

Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
include corresponding SA8775P files.

This is not ideal for the following reasons:
- The approach is not uniform (between QCS9100 and QCS9075), which might
  lead to mistakes.
- The approach ends up duplicating DT code unnecessarily, which can lead
  to issues being patches in the one board file, but not in the other
  file.

If there are any reasons why you want to follow this approach, they must
be a part of the commit message.

> 
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile            |  2 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
>  3 files changed, 94 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@0 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x0>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "sgmii";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "sgmii";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@a {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0xa>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> --
> 2.47.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > 
> > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > subsystem which is available in QCS9100, and it affects thermal
> > management.
> > 
> > Also, between ride and ride-r3 ethernet phy is different.
> > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> 
> Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> include corresponding SA8775P files.
> 
> This is not ideal for the following reasons:
> - The approach is not uniform (between QCS9100 and QCS9075), which might
>   lead to mistakes.
> - The approach ends up duplicating DT code unnecessarily, which can lead
>   to issues being patches in the one board file, but not in the other
>   file.
> 
> If there are any reasons why you want to follow this approach, they must
> be a part of the commit message.
> 

Hi Dmitry,

Initially, we included the DTS [1] file to avoid duplication. However,
based on Krzysztof's previous suggestion [2], we change to this format.

Please let us know how to proceed further on this.

[1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
[2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/

> > 
> > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > ---
> >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> >  3 files changed, 94 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 78613a1bd34a..41cb2bbd3472 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > new file mode 100644
> > index 000000000000..d9a8956d3a76
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +&ethernet0 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&ethernet1 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > +	compatible = "snps,dwmac-mdio";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	sgmii_phy0: phy@8 {
> > +		compatible = "ethernet-phy-id31c3.1c33";
> > +		reg = <0x8>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +
> > +	sgmii_phy1: phy@0 {
> > +		compatible = "ethernet-phy-id31c3.1c33";
> > +		reg = <0x0>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > new file mode 100644
> > index 000000000000..3b524359a72d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +&ethernet0 {
> > +	phy-mode = "sgmii";
> > +};
> > +
> > +&ethernet1 {
> > +	phy-mode = "sgmii";
> > +};
> > +
> > +&mdio {
> > +	compatible = "snps,dwmac-mdio";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	sgmii_phy0: phy@8 {
> > +		compatible = "ethernet-phy-id0141.0dd4";
> > +		reg = <0x8>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +
> > +	sgmii_phy1: phy@a {
> > +		compatible = "ethernet-phy-id0141.0dd4";
> > +		reg = <0xa>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +};
> > --
> > 2.47.0
> > 
> 
> -- 
> With best wishes
> Dmitry


Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Dmitry Baryshkov]

On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > 
> > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > subsystem which is available in QCS9100, and it affects thermal
> > > management.
> > > 
> > > Also, between ride and ride-r3 ethernet phy is different.
> > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > 
> > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > include corresponding SA8775P files.
> > 
> > This is not ideal for the following reasons:
> > - The approach is not uniform (between QCS9100 and QCS9075), which might
> >   lead to mistakes.
> > - The approach ends up duplicating DT code unnecessarily, which can lead
> >   to issues being patches in the one board file, but not in the other
> >   file.
> > 
> > If there are any reasons why you want to follow this approach, they must
> > be a part of the commit message.
> > 
> 
> Hi Dmitry,
> 
> Initially, we included the DTS [1] file to avoid duplication. However,
> based on Krzysztof's previous suggestion [2], we change to this format.
> 
> Please let us know how to proceed further on this.

Krzysztof asked you to include DTSI files instead of including DTS
files. Hope this helps.

> 
> [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> 
> > > 
> > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > ---
> > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > >  3 files changed, 94 insertions(+)
> > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > index 78613a1bd34a..41cb2bbd3472 100644
> > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > new file mode 100644
> > > index 000000000000..d9a8956d3a76
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > @@ -0,0 +1,46 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/*
> > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > + */
> > > +/dts-v1/;
> > > +
> > > +#include "sa8775p-ride.dtsi"
> > > +
> > > +/ {
> > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > +};
> > > +
> > > +&ethernet0 {
> > > +	phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&ethernet1 {
> > > +	phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&mdio {
> > > +	compatible = "snps,dwmac-mdio";
> > > +	#address-cells = <1>;
> > > +	#size-cells = <0>;
> > > +
> > > +	sgmii_phy0: phy@8 {
> > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > +		reg = <0x8>;
> > > +		device_type = "ethernet-phy";
> > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > +		reset-assert-us = <11000>;
> > > +		reset-deassert-us = <70000>;
> > > +	};
> > > +
> > > +	sgmii_phy1: phy@0 {
> > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > +		reg = <0x0>;
> > > +		device_type = "ethernet-phy";
> > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > +		reset-assert-us = <11000>;
> > > +		reset-deassert-us = <70000>;
> > > +	};
> > > +};
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > new file mode 100644
> > > index 000000000000..3b524359a72d
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > @@ -0,0 +1,46 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/*
> > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > + */
> > > +/dts-v1/;
> > > +
> > > +#include "sa8775p-ride.dtsi"
> > > +
> > > +/ {
> > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > +};
> > > +
> > > +&ethernet0 {
> > > +	phy-mode = "sgmii";
> > > +};
> > > +
> > > +&ethernet1 {
> > > +	phy-mode = "sgmii";
> > > +};
> > > +
> > > +&mdio {
> > > +	compatible = "snps,dwmac-mdio";
> > > +	#address-cells = <1>;
> > > +	#size-cells = <0>;
> > > +
> > > +	sgmii_phy0: phy@8 {
> > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > +		reg = <0x8>;
> > > +		device_type = "ethernet-phy";
> > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > +		reset-assert-us = <11000>;
> > > +		reset-deassert-us = <70000>;
> > > +	};
> > > +
> > > +	sgmii_phy1: phy@a {
> > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > +		reg = <0xa>;
> > > +		device_type = "ethernet-phy";
> > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > +		reset-assert-us = <11000>;
> > > +		reset-deassert-us = <70000>;
> > > +	};
> > > +};
> > > --
> > > 2.47.0
> > > 
> > 
> > -- 
> > With best wishes
> > Dmitry
> 
> 
> Thanks & Regards,
> Wasim

-- 
With best wishes
Dmitry

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > 
> > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > subsystem which is available in QCS9100, and it affects thermal
> > > > management.
> > > > 
> > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > 
> > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > include corresponding SA8775P files.
> > > 
> > > This is not ideal for the following reasons:
> > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > >   lead to mistakes.
> > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > >   to issues being patches in the one board file, but not in the other
> > >   file.
> > > 
> > > If there are any reasons why you want to follow this approach, they must
> > > be a part of the commit message.
> > > 
> > 
> > Hi Dmitry,
> > 
> > Initially, we included the DTS [1] file to avoid duplication. However,
> > based on Krzysztof's previous suggestion [2], we change to this format.
> > 
> > Please let us know how to proceed further on this.
> 
> Krzysztof asked you to include DTSI files instead of including DTS
> files. Hope this helps.

Are you suggesting that we should also modify the 9100-ride files to
include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
However, this would result in the duplication of Ethernet nodes in all
the ride board files. Would that be acceptable?

> 
> > 
> > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > 
> > > > 
> > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > ---
> > > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > > >  3 files changed, 94 insertions(+)
> > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > new file mode 100644
> > > > index 000000000000..d9a8956d3a76
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > @@ -0,0 +1,46 @@
> > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > +/*
> > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > + */
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sa8775p-ride.dtsi"
> > > > +
> > > > +/ {
> > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > +};
> > > > +
> > > > +&ethernet0 {
> > > > +	phy-mode = "2500base-x";
> > > > +};
> > > > +
> > > > +&ethernet1 {
> > > > +	phy-mode = "2500base-x";
> > > > +};
> > > > +
> > > > +&mdio {
> > > > +	compatible = "snps,dwmac-mdio";
> > > > +	#address-cells = <1>;
> > > > +	#size-cells = <0>;
> > > > +
> > > > +	sgmii_phy0: phy@8 {
> > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > +		reg = <0x8>;
> > > > +		device_type = "ethernet-phy";
> > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > +		reset-assert-us = <11000>;
> > > > +		reset-deassert-us = <70000>;
> > > > +	};
> > > > +
> > > > +	sgmii_phy1: phy@0 {
> > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > +		reg = <0x0>;
> > > > +		device_type = "ethernet-phy";
> > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > +		reset-assert-us = <11000>;
> > > > +		reset-deassert-us = <70000>;
> > > > +	};
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > new file mode 100644
> > > > index 000000000000..3b524359a72d
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > @@ -0,0 +1,46 @@
> > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > +/*
> > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > + */
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sa8775p-ride.dtsi"
> > > > +
> > > > +/ {
> > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > +};
> > > > +
> > > > +&ethernet0 {
> > > > +	phy-mode = "sgmii";
> > > > +};
> > > > +
> > > > +&ethernet1 {
> > > > +	phy-mode = "sgmii";
> > > > +};
> > > > +
> > > > +&mdio {
> > > > +	compatible = "snps,dwmac-mdio";
> > > > +	#address-cells = <1>;
> > > > +	#size-cells = <0>;
> > > > +
> > > > +	sgmii_phy0: phy@8 {
> > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > +		reg = <0x8>;
> > > > +		device_type = "ethernet-phy";
> > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > +		reset-assert-us = <11000>;
> > > > +		reset-deassert-us = <70000>;
> > > > +	};
> > > > +
> > > > +	sgmii_phy1: phy@a {
> > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > +		reg = <0xa>;
> > > > +		device_type = "ethernet-phy";
> > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > +		reset-assert-us = <11000>;
> > > > +		reset-deassert-us = <70000>;
> > > > +	};
> > > > +};
> > > > --
> > > > 2.47.0
> > > > 
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> > 
> > 
> > Thanks & Regards,
> > Wasim
> 
> -- 
> With best wishes
> Dmitry


Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Dmitry Baryshkov]

On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > 
> > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > management.
> > > > > 
> > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > 
> > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > include corresponding SA8775P files.
> > > > 
> > > > This is not ideal for the following reasons:
> > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > >   lead to mistakes.
> > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > >   to issues being patches in the one board file, but not in the other
> > > >   file.
> > > > 
> > > > If there are any reasons why you want to follow this approach, they must
> > > > be a part of the commit message.
> > > > 
> > > 
> > > Hi Dmitry,
> > > 
> > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > 
> > > Please let us know how to proceed further on this.
> > 
> > Krzysztof asked you to include DTSI files instead of including DTS
> > files. Hope this helps.
> 
> Are you suggesting that we should also modify the 9100-ride files to
> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> However, this would result in the duplication of Ethernet nodes in all
> the ride board files. Would that be acceptable?

git mv foo.dts foo.dtsi
echo '#include "foo.dtsi"' > foo.dts
git add foo.dts
git commit

> 
> > 
> > > 
> > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > 
> > > > > 
> > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > ---
> > > > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > > > >  3 files changed, 94 insertions(+)
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > 
> > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > new file mode 100644
> > > > > index 000000000000..d9a8956d3a76
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > @@ -0,0 +1,46 @@
> > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > +/*
> > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > + */
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "sa8775p-ride.dtsi"
> > > > > +
> > > > > +/ {
> > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > +};
> > > > > +
> > > > > +&ethernet0 {
> > > > > +	phy-mode = "2500base-x";
> > > > > +};
> > > > > +
> > > > > +&ethernet1 {
> > > > > +	phy-mode = "2500base-x";
> > > > > +};
> > > > > +
> > > > > +&mdio {
> > > > > +	compatible = "snps,dwmac-mdio";
> > > > > +	#address-cells = <1>;
> > > > > +	#size-cells = <0>;
> > > > > +
> > > > > +	sgmii_phy0: phy@8 {
> > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > +		reg = <0x8>;
> > > > > +		device_type = "ethernet-phy";
> > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > +		reset-assert-us = <11000>;
> > > > > +		reset-deassert-us = <70000>;
> > > > > +	};
> > > > > +
> > > > > +	sgmii_phy1: phy@0 {
> > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > +		reg = <0x0>;
> > > > > +		device_type = "ethernet-phy";
> > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > +		reset-assert-us = <11000>;
> > > > > +		reset-deassert-us = <70000>;
> > > > > +	};
> > > > > +};
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > new file mode 100644
> > > > > index 000000000000..3b524359a72d
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > @@ -0,0 +1,46 @@
> > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > +/*
> > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > + */
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "sa8775p-ride.dtsi"
> > > > > +
> > > > > +/ {
> > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > +};
> > > > > +
> > > > > +&ethernet0 {
> > > > > +	phy-mode = "sgmii";
> > > > > +};
> > > > > +
> > > > > +&ethernet1 {
> > > > > +	phy-mode = "sgmii";
> > > > > +};
> > > > > +
> > > > > +&mdio {
> > > > > +	compatible = "snps,dwmac-mdio";
> > > > > +	#address-cells = <1>;
> > > > > +	#size-cells = <0>;
> > > > > +
> > > > > +	sgmii_phy0: phy@8 {
> > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > +		reg = <0x8>;
> > > > > +		device_type = "ethernet-phy";
> > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > +		reset-assert-us = <11000>;
> > > > > +		reset-deassert-us = <70000>;
> > > > > +	};
> > > > > +
> > > > > +	sgmii_phy1: phy@a {
> > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > +		reg = <0xa>;
> > > > > +		device_type = "ethernet-phy";
> > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > +		reset-assert-us = <11000>;
> > > > > +		reset-deassert-us = <70000>;
> > > > > +	};
> > > > > +};
> > > > > --
> > > > > 2.47.0
> > > > > 
> > > > 
> > > > -- 
> > > > With best wishes
> > > > Dmitry
> > > 
> > > 
> > > Thanks & Regards,
> > > Wasim
> > 
> > -- 
> > With best wishes
> > Dmitry
> 
> 
> Thanks & Regards,
> Wasim

-- 
With best wishes
Dmitry

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > > 
> > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > management.
> > > > > > 
> > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > > 
> > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > include corresponding SA8775P files.
> > > > > 
> > > > > This is not ideal for the following reasons:
> > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > >   lead to mistakes.
> > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > >   to issues being patches in the one board file, but not in the other
> > > > >   file.
> > > > > 
> > > > > If there are any reasons why you want to follow this approach, they must
> > > > > be a part of the commit message.
> > > > > 
> > > > 
> > > > Hi Dmitry,
> > > > 
> > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > > 
> > > > Please let us know how to proceed further on this.
> > > 
> > > Krzysztof asked you to include DTSI files instead of including DTS
> > > files. Hope this helps.
> > 
> > Are you suggesting that we should also modify the 9100-ride files to
> > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > However, this would result in the duplication of Ethernet nodes in all
> > the ride board files. Would that be acceptable?
> 
> git mv foo.dts foo.dtsi
> echo '#include "foo.dtsi"' > foo.dts
> git add foo.dts
> git commit
> 

We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
they represent different platforms. In patch [1], we included these DTS
files to reuse the common hardware nodes.

Could you please advise on how we should proceed with the following
approaches?

a) Previous approach [1]:
Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
platform DTS, similar to the qcs9100-ride platform DTS. This approach
avoids duplicating Ethernet nodes and maintains uniformity. However, it
involves including the DTS file directly.

b) Current suggestion:
Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
modify the qcs9100-ride platform DTS files to maintain uniformity. This
approach results in duplicating Ethernet nodes.

Please let us know your recommendation to finalize the DT structure.

[1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/

> > 
> > > 
> > > > 
> > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > > 
> > > > > > 
> > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > ---
> > > > > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > > > > >  3 files changed, 94 insertions(+)
> > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > 
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > new file mode 100644
> > > > > > index 000000000000..d9a8956d3a76
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > @@ -0,0 +1,46 @@
> > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > +/*
> > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > + */
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > +};
> > > > > > +
> > > > > > +&ethernet0 {
> > > > > > +	phy-mode = "2500base-x";
> > > > > > +};
> > > > > > +
> > > > > > +&ethernet1 {
> > > > > > +	phy-mode = "2500base-x";
> > > > > > +};
> > > > > > +
> > > > > > +&mdio {
> > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > +	#address-cells = <1>;
> > > > > > +	#size-cells = <0>;
> > > > > > +
> > > > > > +	sgmii_phy0: phy@8 {
> > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > +		reg = <0x8>;
> > > > > > +		device_type = "ethernet-phy";
> > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > +		reset-assert-us = <11000>;
> > > > > > +		reset-deassert-us = <70000>;
> > > > > > +	};
> > > > > > +
> > > > > > +	sgmii_phy1: phy@0 {
> > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > +		reg = <0x0>;
> > > > > > +		device_type = "ethernet-phy";
> > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > +		reset-assert-us = <11000>;
> > > > > > +		reset-deassert-us = <70000>;
> > > > > > +	};
> > > > > > +};
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > new file mode 100644
> > > > > > index 000000000000..3b524359a72d
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > @@ -0,0 +1,46 @@
> > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > +/*
> > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > + */
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > +};
> > > > > > +
> > > > > > +&ethernet0 {
> > > > > > +	phy-mode = "sgmii";
> > > > > > +};
> > > > > > +
> > > > > > +&ethernet1 {
> > > > > > +	phy-mode = "sgmii";
> > > > > > +};
> > > > > > +
> > > > > > +&mdio {
> > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > +	#address-cells = <1>;
> > > > > > +	#size-cells = <0>;
> > > > > > +
> > > > > > +	sgmii_phy0: phy@8 {
> > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > +		reg = <0x8>;
> > > > > > +		device_type = "ethernet-phy";
> > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > +		reset-assert-us = <11000>;
> > > > > > +		reset-deassert-us = <70000>;
> > > > > > +	};
> > > > > > +
> > > > > > +	sgmii_phy1: phy@a {
> > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > +		reg = <0xa>;
> > > > > > +		device_type = "ethernet-phy";
> > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > +		reset-assert-us = <11000>;
> > > > > > +		reset-deassert-us = <70000>;
> > > > > > +	};
> > > > > > +};
> > > > > > --
> > > > > > 2.47.0
> > > > > > 
> > > > > 
> > > > > -- 
> > > > > With best wishes
> > > > > Dmitry
> > > > 
> > > > 
> > > > Thanks & Regards,
> > > > Wasim
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> > 
> > 
> > Thanks & Regards,
> > Wasim
> 
> -- 
> With best wishes
> Dmitry

Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Dmitry Baryshkov]

On Sat, Jan 04, 2025 at 12:29:07AM +0530, Wasim Nazir wrote:
> On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> > On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > > > 
> > > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > > management.
> > > > > > > 
> > > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > > > 
> > > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > > include corresponding SA8775P files.
> > > > > > 
> > > > > > This is not ideal for the following reasons:
> > > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > > >   lead to mistakes.
> > > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > > >   to issues being patches in the one board file, but not in the other
> > > > > >   file.
> > > > > > 
> > > > > > If there are any reasons why you want to follow this approach, they must
> > > > > > be a part of the commit message.
> > > > > > 
> > > > > 
> > > > > Hi Dmitry,
> > > > > 
> > > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > > > 
> > > > > Please let us know how to proceed further on this.
> > > > 
> > > > Krzysztof asked you to include DTSI files instead of including DTS
> > > > files. Hope this helps.
> > > 
> > > Are you suggesting that we should also modify the 9100-ride files to
> > > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > > However, this would result in the duplication of Ethernet nodes in all
> > > the ride board files. Would that be acceptable?
> > 
> > git mv foo.dts foo.dtsi
> > echo '#include "foo.dtsi"' > foo.dts
> > git add foo.dts
> > git commit
> > 
> 
> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> they represent different platforms. In patch [1], we included these DTS
> files to reuse the common hardware nodes.
> 
> Could you please advise on how we should proceed with the following
> approaches?
> 
> a) Previous approach [1]:
> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> involves including the DTS file directly.
> 
> b) Current suggestion:
> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> approach results in duplicating Ethernet nodes.
> 
> Please let us know your recommendation to finalize the DT structure.

sa8775p.dtsi
`__sa8775p-ride.dtsi
   `__sa8775p-ride-r2.dtsi
      `__sa8775p-ride.dts
      `__qcs9100-ride.dts
      `__qcs9075-ride.dts
   `__sa8775p-ride-r3.dtsi
      `__sa8775p-ride-r3.dts
      `__qcs9100-ride-r3.dts
      `__qcs9075-ride-r3.dts

> 
> [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> 
> > > 
> > > > 
> > > > > 
> > > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > > > 
> > > > > > > 
> > > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > > ---
> > > > > > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > > > > > >  3 files changed, 94 insertions(+)
> > > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > 
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..d9a8956d3a76
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > @@ -0,0 +1,46 @@
> > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > +/*
> > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > + */
> > > > > > > +/dts-v1/;
> > > > > > > +
> > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > +
> > > > > > > +/ {
> > > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&ethernet0 {
> > > > > > > +	phy-mode = "2500base-x";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&ethernet1 {
> > > > > > > +	phy-mode = "2500base-x";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&mdio {
> > > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > > +	#address-cells = <1>;
> > > > > > > +	#size-cells = <0>;
> > > > > > > +
> > > > > > > +	sgmii_phy0: phy@8 {
> > > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > +		reg = <0x8>;
> > > > > > > +		device_type = "ethernet-phy";
> > > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > +		reset-assert-us = <11000>;
> > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > +	};
> > > > > > > +
> > > > > > > +	sgmii_phy1: phy@0 {
> > > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > +		reg = <0x0>;
> > > > > > > +		device_type = "ethernet-phy";
> > > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > +		reset-assert-us = <11000>;
> > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > +	};
> > > > > > > +};
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..3b524359a72d
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > @@ -0,0 +1,46 @@
> > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > +/*
> > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > + */
> > > > > > > +/dts-v1/;
> > > > > > > +
> > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > +
> > > > > > > +/ {
> > > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&ethernet0 {
> > > > > > > +	phy-mode = "sgmii";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&ethernet1 {
> > > > > > > +	phy-mode = "sgmii";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&mdio {
> > > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > > +	#address-cells = <1>;
> > > > > > > +	#size-cells = <0>;
> > > > > > > +
> > > > > > > +	sgmii_phy0: phy@8 {
> > > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > +		reg = <0x8>;
> > > > > > > +		device_type = "ethernet-phy";
> > > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > +		reset-assert-us = <11000>;
> > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > +	};
> > > > > > > +
> > > > > > > +	sgmii_phy1: phy@a {
> > > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > +		reg = <0xa>;
> > > > > > > +		device_type = "ethernet-phy";
> > > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > +		reset-assert-us = <11000>;
> > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > +	};
> > > > > > > +};
> > > > > > > --
> > > > > > > 2.47.0
> > > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > With best wishes
> > > > > > Dmitry
> > > > > 
> > > > > 
> > > > > Thanks & Regards,
> > > > > Wasim
> > > > 
> > > > -- 
> > > > With best wishes
> > > > Dmitry
> > > 
> > > 
> > > Thanks & Regards,
> > > Wasim
> > 
> > -- 
> > With best wishes
> > Dmitry
> 
> Thanks & Regards,
> Wasim

-- 
With best wishes
Dmitry

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 03/01/2025 20:58, Dmitry Baryshkov wrote:
>>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
>>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
>>>>>>
>>>>>> Please let us know how to proceed further on this.
>>>>>
>>>>> Krzysztof asked you to include DTSI files instead of including DTS
>>>>> files. Hope this helps.
>>>>
>>>> Are you suggesting that we should also modify the 9100-ride files to
>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
>>>> However, this would result in the duplication of Ethernet nodes in all
>>>> the ride board files. Would that be acceptable?
>>>
>>> git mv foo.dts foo.dtsi
>>> echo '#include "foo.dtsi"' > foo.dts
>>> git add foo.dts
>>> git commit
>>>
>>
>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
>> they represent different platforms. In patch [1], we included these DTS
>> files to reuse the common hardware nodes.
>>
>> Could you please advise on how we should proceed with the following
>> approaches?
>>
>> a) Previous approach [1]:
>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
>> platform DTS, similar to the qcs9100-ride platform DTS. This approach
>> avoids duplicating Ethernet nodes and maintains uniformity. However, it
>> involves including the DTS file directly.
>>
>> b) Current suggestion:
>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
>> modify the qcs9100-ride platform DTS files to maintain uniformity. This
>> approach results in duplicating Ethernet nodes.
>>
>> Please let us know your recommendation to finalize the DT structure.
> 
> sa8775p.dtsi
> `__sa8775p-ride.dtsi
>    `__sa8775p-ride-r2.dtsi
>       `__sa8775p-ride.dts
>       `__qcs9100-ride.dts
>       `__qcs9075-ride.dts
>    `__sa8775p-ride-r3.dtsi
>       `__sa8775p-ride-r3.dts
>       `__qcs9100-ride-r3.dts
>       `__qcs9075-ride-r3.dts
> 
Wasim and all other copy-pasters of sa8775p-ride,

Just to recap, qcs9100 contributions started this terrible pattern of
board including a board. Unfortunately qcs9100 was merged, so that ship
has sailed.

This patchset was going the same way, because poor choices like to keep
spreading, but at one of previous versions I noticed it and objected.

This v5 however solves above problem by duplicating the nodes.

Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
same board, but none of this was communicated. I checked all the commit
msgs in this patchset and nothing explained about it. What annoys me is
that you do not communicate your design forcing us to accept poor DTS or
forcing us to guess and make poor judgments.

Come with proper hardware description and split out shared parts, like
motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
But assuming there are shared parts because I am pretty sure you will
pick my comments when it suits you without actually following them fully
and without understanding and explaining to us your own hardware.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote:
> On 03/01/2025 20:58, Dmitry Baryshkov wrote:
> >>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
> >>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
> >>>>>>
> >>>>>> Please let us know how to proceed further on this.
> >>>>>
> >>>>> Krzysztof asked you to include DTSI files instead of including DTS
> >>>>> files. Hope this helps.
> >>>>
> >>>> Are you suggesting that we should also modify the 9100-ride files to
> >>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> >>>> However, this would result in the duplication of Ethernet nodes in all
> >>>> the ride board files. Would that be acceptable?
> >>>
> >>> git mv foo.dts foo.dtsi
> >>> echo '#include "foo.dtsi"' > foo.dts
> >>> git add foo.dts
> >>> git commit
> >>>
> >>
> >> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> >> they represent different platforms. In patch [1], we included these DTS
> >> files to reuse the common hardware nodes.
> >>
> >> Could you please advise on how we should proceed with the following
> >> approaches?
> >>
> >> a) Previous approach [1]:
> >> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> >> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> >> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> >> involves including the DTS file directly.
> >>
> >> b) Current suggestion:
> >> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> >> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> >> approach results in duplicating Ethernet nodes.
> >>
> >> Please let us know your recommendation to finalize the DT structure.
> > 
> > sa8775p.dtsi
> > `__sa8775p-ride.dtsi
> >    `__sa8775p-ride-r2.dtsi
> >       `__sa8775p-ride.dts
> >       `__qcs9100-ride.dts
> >       `__qcs9075-ride.dts
> >    `__sa8775p-ride-r3.dtsi
> >       `__sa8775p-ride-r3.dts
> >       `__qcs9100-ride-r3.dts
> >       `__qcs9075-ride-r3.dts
> > 
> Wasim and all other copy-pasters of sa8775p-ride,
> 
> Just to recap, qcs9100 contributions started this terrible pattern of
> board including a board. Unfortunately qcs9100 was merged, so that ship
> has sailed.
> 
> This patchset was going the same way, because poor choices like to keep
> spreading, but at one of previous versions I noticed it and objected.
> 
> This v5 however solves above problem by duplicating the nodes.
> 
> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
> same board, but none of this was communicated. I checked all the commit
> msgs in this patchset and nothing explained about it. What annoys me is
> that you do not communicate your design forcing us to accept poor DTS or
> forcing us to guess and make poor judgments.
> 
> Come with proper hardware description and split out shared parts, like
> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
> But assuming there are shared parts because I am pretty sure you will
> pick my comments when it suits you without actually following them fully
> and without understanding and explaining to us your own hardware.
> 

Hi Krzysztof,

Here is the pictorial flow showing how SoCs are derived and what all boards
are supported.

  +---------------------------------------------------------------------+
  |                                                                     |
  |								 sa8775p                                |
  |					        		|                                   |
  |			+-----------------------+-----------------------+           |
  |			|				  		|			    		|           |
  |			v				  		|				    	v           |
  |		 qcs9100			  		|		    		 qcs9075        |
  |			|				  		|			    		|           |
  |			v					    v						v           |
  |		  (IOT)				     (AUTO)					  (IOT)         |
  |	qcs9100-ride.dts		sa8775p-ride.dts		qcs9075-ride.dts    |
  |	qcs9100-ride-r3.dts		sa8775p-ride-r3.dts		qcs9075-ride-r3.dts |
  |													qcs9075-rb8.dts     |
  |                                                                     |
  +---------------------------------------------------------------------+

Although we included details about the QCS9075 and QCS9100 in the cover
letter and commit message, explaining their differences and common
origin from the SA8775P SOC, the new DT structure suggested by Dmitry
should make things clearer. This structure properly splits common parts
and enhances reusability.

> Best regards,
> Krzysztof

Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Thu, Jan 09, 2025 at 08:17:54PM +0530, Wasim Nazir wrote:
> On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote:
> > On 03/01/2025 20:58, Dmitry Baryshkov wrote:
> > >>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
> > >>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
> > >>>>>>
> > >>>>>> Please let us know how to proceed further on this.
> > >>>>>
> > >>>>> Krzysztof asked you to include DTSI files instead of including DTS
> > >>>>> files. Hope this helps.
> > >>>>
> > >>>> Are you suggesting that we should also modify the 9100-ride files to
> > >>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > >>>> However, this would result in the duplication of Ethernet nodes in all
> > >>>> the ride board files. Would that be acceptable?
> > >>>
> > >>> git mv foo.dts foo.dtsi
> > >>> echo '#include "foo.dtsi"' > foo.dts
> > >>> git add foo.dts
> > >>> git commit
> > >>>
> > >>
> > >> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> > >> they represent different platforms. In patch [1], we included these DTS
> > >> files to reuse the common hardware nodes.
> > >>
> > >> Could you please advise on how we should proceed with the following
> > >> approaches?
> > >>
> > >> a) Previous approach [1]:
> > >> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> > >> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> > >> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> > >> involves including the DTS file directly.
> > >>
> > >> b) Current suggestion:
> > >> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> > >> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> > >> approach results in duplicating Ethernet nodes.
> > >>
> > >> Please let us know your recommendation to finalize the DT structure.
> > > 
> > > sa8775p.dtsi
> > > `__sa8775p-ride.dtsi
> > >    `__sa8775p-ride-r2.dtsi
> > >       `__sa8775p-ride.dts
> > >       `__qcs9100-ride.dts
> > >       `__qcs9075-ride.dts
> > >    `__sa8775p-ride-r3.dtsi
> > >       `__sa8775p-ride-r3.dts
> > >       `__qcs9100-ride-r3.dts
> > >       `__qcs9075-ride-r3.dts
> > > 
> > Wasim and all other copy-pasters of sa8775p-ride,
> > 
> > Just to recap, qcs9100 contributions started this terrible pattern of
> > board including a board. Unfortunately qcs9100 was merged, so that ship
> > has sailed.
> > 
> > This patchset was going the same way, because poor choices like to keep
> > spreading, but at one of previous versions I noticed it and objected.
> > 
> > This v5 however solves above problem by duplicating the nodes.
> > 
> > Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
> > same board, but none of this was communicated. I checked all the commit
> > msgs in this patchset and nothing explained about it. What annoys me is
> > that you do not communicate your design forcing us to accept poor DTS or
> > forcing us to guess and make poor judgments.
> > 
> > Come with proper hardware description and split out shared parts, like
> > motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
> > But assuming there are shared parts because I am pretty sure you will
> > pick my comments when it suits you without actually following them fully
> > and without understanding and explaining to us your own hardware.
> > 
> 
> Hi Krzysztof,
> 
> Here is the pictorial flow showing how SoCs are derived and what all boards
> are supported.
> 
+-----------------------------------------------------------------------+
|                                                                       |
|                                sa8775p                                |
|                                   |                                   |
|           +-----------------------+-----------------------+           |
|           |                       |                       |           |
|           v                       |                       v           |
|        qcs9100                    |                    qcs9075        |
|           |                       |                       |           |
|           v                       v                       v           |
|         (IOT)                  (AUTO)                   (IOT)         |
|   qcs9100-ride.dts        sa8775p-ride.dts        qcs9075-ride.dts    |
|   qcs9100-ride-r3.dts     sa8775p-ride-r3.dts     qcs9075-ride-r3.dts |
|                                                   qcs9075-rb8.dts     |
|                                                                       |
+-----------------------------------------------------------------------+
Updating it as previous one is messed up with whitespaces.

> 
> Although we included details about the QCS9075 and QCS9100 in the cover
> letter and commit message, explaining their differences and common
> origin from the SA8775P SOC, the new DT structure suggested by Dmitry
> should make things clearer. This structure properly splits common parts
> and enhances reusability.
> 
> > Best regards,
> > Krzysztof
> 
> Thanks & Regards,
> Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 09/01/2025 15:47, Wasim Nazir wrote:
> On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote:
>> On 03/01/2025 20:58, Dmitry Baryshkov wrote:
>>>>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
>>>>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
>>>>>>>>
>>>>>>>> Please let us know how to proceed further on this.
>>>>>>>
>>>>>>> Krzysztof asked you to include DTSI files instead of including DTS
>>>>>>> files. Hope this helps.
>>>>>>
>>>>>> Are you suggesting that we should also modify the 9100-ride files to
>>>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
>>>>>> However, this would result in the duplication of Ethernet nodes in all
>>>>>> the ride board files. Would that be acceptable?
>>>>>
>>>>> git mv foo.dts foo.dtsi
>>>>> echo '#include "foo.dtsi"' > foo.dts
>>>>> git add foo.dts
>>>>> git commit
>>>>>
>>>>
>>>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
>>>> they represent different platforms. In patch [1], we included these DTS
>>>> files to reuse the common hardware nodes.
>>>>
>>>> Could you please advise on how we should proceed with the following
>>>> approaches?
>>>>
>>>> a) Previous approach [1]:
>>>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
>>>> platform DTS, similar to the qcs9100-ride platform DTS. This approach
>>>> avoids duplicating Ethernet nodes and maintains uniformity. However, it
>>>> involves including the DTS file directly.
>>>>
>>>> b) Current suggestion:
>>>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
>>>> modify the qcs9100-ride platform DTS files to maintain uniformity. This
>>>> approach results in duplicating Ethernet nodes.
>>>>
>>>> Please let us know your recommendation to finalize the DT structure.
>>>
>>> sa8775p.dtsi
>>> `__sa8775p-ride.dtsi
>>>    `__sa8775p-ride-r2.dtsi
>>>       `__sa8775p-ride.dts
>>>       `__qcs9100-ride.dts
>>>       `__qcs9075-ride.dts
>>>    `__sa8775p-ride-r3.dtsi
>>>       `__sa8775p-ride-r3.dts
>>>       `__qcs9100-ride-r3.dts
>>>       `__qcs9075-ride-r3.dts
>>>
>> Wasim and all other copy-pasters of sa8775p-ride,
>>
>> Just to recap, qcs9100 contributions started this terrible pattern of
>> board including a board. Unfortunately qcs9100 was merged, so that ship
>> has sailed.
>>
>> This patchset was going the same way, because poor choices like to keep
>> spreading, but at one of previous versions I noticed it and objected.
>>
>> This v5 however solves above problem by duplicating the nodes.
>>
>> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
>> same board, but none of this was communicated. I checked all the commit
>> msgs in this patchset and nothing explained about it. What annoys me is
>> that you do not communicate your design forcing us to accept poor DTS or
>> forcing us to guess and make poor judgments.
>>
>> Come with proper hardware description and split out shared parts, like
>> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
>> But assuming there are shared parts because I am pretty sure you will
>> pick my comments when it suits you without actually following them fully
>> and without understanding and explaining to us your own hardware.
>>
> 
> Hi Krzysztof,
> 
> Here is the pictorial flow showing how SoCs are derived and what all boards
> are supported.
> 
>   +---------------------------------------------------------------------+
>   |                                                                     |
>   |								 sa8775p                                |
>   |					        		|                                   |
>   |			+-----------------------+-----------------------+           |
>   |			|				  		|			    		|           |
>   |			v				  		|				    	v           |
>   |		 qcs9100			  		|		    		 qcs9075        |
>   |			|				  		|			    		|           |
>   |			v					    v						v           |
>   |		  (IOT)				     (AUTO)					  (IOT)         |
>   |	qcs9100-ride.dts		sa8775p-ride.dts		qcs9075-ride.dts    |
>   |	qcs9100-ride-r3.dts		sa8775p-ride-r3.dts		qcs9075-ride-r3.dts |
>   |													qcs9075-rb8.dts     |
>   |                                                                     |
>   +---------------------------------------------------------------------+

The the SoC, I am asking about the board. Why each of them is for
example r3?

So this is not sufficient explanation, nothing about the board, and
again just look Renesas and NXP.


Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Thu, Jan 09, 2025 at 05:16:25PM +0100, Krzysztof Kozlowski wrote:
> On 09/01/2025 15:47, Wasim Nazir wrote:
> > On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote:
> >> On 03/01/2025 20:58, Dmitry Baryshkov wrote:
> >>>>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
> >>>>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
> >>>>>>>>
> >>>>>>>> Please let us know how to proceed further on this.
> >>>>>>>
> >>>>>>> Krzysztof asked you to include DTSI files instead of including DTS
> >>>>>>> files. Hope this helps.
> >>>>>>
> >>>>>> Are you suggesting that we should also modify the 9100-ride files to
> >>>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> >>>>>> However, this would result in the duplication of Ethernet nodes in all
> >>>>>> the ride board files. Would that be acceptable?
> >>>>>
> >>>>> git mv foo.dts foo.dtsi
> >>>>> echo '#include "foo.dtsi"' > foo.dts
> >>>>> git add foo.dts
> >>>>> git commit
> >>>>>
> >>>>
> >>>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> >>>> they represent different platforms. In patch [1], we included these DTS
> >>>> files to reuse the common hardware nodes.
> >>>>
> >>>> Could you please advise on how we should proceed with the following
> >>>> approaches?
> >>>>
> >>>> a) Previous approach [1]:
> >>>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> >>>> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> >>>> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> >>>> involves including the DTS file directly.
> >>>>
> >>>> b) Current suggestion:
> >>>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> >>>> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> >>>> approach results in duplicating Ethernet nodes.
> >>>>
> >>>> Please let us know your recommendation to finalize the DT structure.
> >>>
> >>> sa8775p.dtsi
> >>> `__sa8775p-ride.dtsi
> >>>    `__sa8775p-ride-r2.dtsi
> >>>       `__sa8775p-ride.dts
> >>>       `__qcs9100-ride.dts
> >>>       `__qcs9075-ride.dts
> >>>    `__sa8775p-ride-r3.dtsi
> >>>       `__sa8775p-ride-r3.dts
> >>>       `__qcs9100-ride-r3.dts
> >>>       `__qcs9075-ride-r3.dts
> >>>
> >> Wasim and all other copy-pasters of sa8775p-ride,
> >>
> >> Just to recap, qcs9100 contributions started this terrible pattern of
> >> board including a board. Unfortunately qcs9100 was merged, so that ship
> >> has sailed.
> >>
> >> This patchset was going the same way, because poor choices like to keep
> >> spreading, but at one of previous versions I noticed it and objected.
> >>
> >> This v5 however solves above problem by duplicating the nodes.
> >>
> >> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
> >> same board, but none of this was communicated. I checked all the commit
> >> msgs in this patchset and nothing explained about it. What annoys me is
> >> that you do not communicate your design forcing us to accept poor DTS or
> >> forcing us to guess and make poor judgments.
> >>
> >> Come with proper hardware description and split out shared parts, like
> >> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
> >> But assuming there are shared parts because I am pretty sure you will
> >> pick my comments when it suits you without actually following them fully
> >> and without understanding and explaining to us your own hardware.
> >>
> > 
> > Hi Krzysztof,
> > 
> > Here is the pictorial flow showing how SoCs are derived and what all boards
> > are supported.
> > 
> >   +---------------------------------------------------------------------+
> >   |                                                                     |
> >   |								 sa8775p                                |
> >   |					        		|                                   |
> >   |			+-----------------------+-----------------------+           |
> >   |			|				  		|			    		|           |
> >   |			v				  		|				    	v           |
> >   |		 qcs9100			  		|		    		 qcs9075        |
> >   |			|				  		|			    		|           |
> >   |			v					    v						v           |
> >   |		  (IOT)				     (AUTO)					  (IOT)         |
> >   |	qcs9100-ride.dts		sa8775p-ride.dts		qcs9075-ride.dts    |
> >   |	qcs9100-ride-r3.dts		sa8775p-ride-r3.dts		qcs9075-ride-r3.dts |
> >   |													qcs9075-rb8.dts     |
> >   |                                                                     |
> >   +---------------------------------------------------------------------+
> 
> The the SoC, I am asking about the board. Why each of them is for
> example r3?
> 
> So this is not sufficient explanation, nothing about the board, and
> again just look Renesas and NXP.
> 

Hi Krzysztof,

sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
safety capabilities and memory map, serving different purpose.
Ride & Ride-r3 are different boards based on ethernet capabilities and
are compatible with all the SoCs mentioned.

With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
all of which we need.
- sa8775p-ride.dts is auto grade Ride platform with safety feature.
- qcs9100-ride.dts is IOT grade Ride platform with safety feature.
- qcs9075-ride.dts is IOT grade Ride platform without safety feature.

Since the Ride-r3 boards are essentially Ride boards with Ethernet
modifications, we can convert the Ride-r3 DTS to overlays.

Please let me know if this solution works for you.

> 
> Best regards,
> Krzysztof

Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 15/01/2025 06:48, Wasim Nazir wrote:
>> The the SoC, I am asking about the board. Why each of them is for
>> example r3?
>>
>> So this is not sufficient explanation, nothing about the board, and
>> again just look Renesas and NXP.
>>
> 
> Hi Krzysztof,
> 
> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
> safety capabilities and memory map, serving different purpose.
> Ride & Ride-r3 are different boards based on ethernet capabilities and
> are compatible with all the SoCs mentioned.

Compatible? What does it mean for a board?

Third time: did you look how other vendors do it?

> 
> With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
> all of which we need.
> - sa8775p-ride.dts is auto grade Ride platform with safety feature.
> - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
> - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
> 
> Since the Ride-r3 boards are essentially Ride boards with Ethernet
> modifications, we can convert the Ride-r3 DTS to overlays.
How one board can be with multiple SoCs? If it is soldered, it's close
to impossible - that's just not the same board. If it is not soldered,
why you are not explaining it? What is Ride board? What is there? What
can go there? How it can be used in other SoCs? Or for which SoCs? Is
there a datasheet available?

You keep repeating my about SoC and I keep responding the same: don't care.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote:
> On 15/01/2025 06:48, Wasim Nazir wrote:
> >> The the SoC, I am asking about the board. Why each of them is for
> >> example r3?
> >>
> >> So this is not sufficient explanation, nothing about the board, and
> >> again just look Renesas and NXP.
> >>
> > 
> > Hi Krzysztof,
> > 
> > sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
> > safety capabilities and memory map, serving different purpose.
> > Ride & Ride-r3 are different boards based on ethernet capabilities and
> > are compatible with all the SoCs mentioned.
> 

Hi Krzysztof,

> Compatible? What does it mean for a board?
> 

Ride board is based on multiple daughter cards (SOC-card, display,
camera, ethernet, pcie, sensor, etc.).

The SOC is not directly soldered to Ride board, instead SOC is soldered
on SIP (System in Package) card which can be mounted on SOC-daughter card of
Ride board.
	- SoC => SIP-card => SOC-daughter-card (Ride)

Together with SIP cards and other daughter cards we are creating different
<soc>-Ride Variants with differences in memory map & thermal mitigations.

The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the
SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP
cards, except an additional third party SIL-PMIC for SAIL, which is not
present in QCS9075 Ride.

Other daughter cards remains same for <soc>-Ride variants, except
ethernet card which is different for <soc>-Ride rev3 variants.

So the Ride board (combination of daughter cards) is same across the SIP,
while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075.

> Third time: did you look how other vendors do it?
> 

Yes, we have reviewed other vendors. However, please feel free to share
any specific reference you would like us to follow.

Here are few reference files we found from other vendors where similar
tasks are performed which includes code refactoring and HW modularity:
 - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts
 - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts
 - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi,
   px30-engicam-px30-core-ctouch2.dts

In our case along with describing the HW, code refactoring is also done
which might be causing confusion, but we are ready for any inputs for
correction.

Putting this pictorial diagram for updated DT structure depicting our HW.
 - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having
   SoC, PMICs, Memory-map updates.
 - qcom-ride-common.dtsi specifying ride daughter boards, here we are
   doing code refactoring also as this is common for all ride boards.
 - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which
   uses 2.5G phy and can be overlayed to ride boards to get ride-r3.
   By default ride uses 1G phy.
 - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product
   name. We will be changing this in next patch series.

+-----------------------------------------------------------------------------------------------------------------------------------------------+
|                                                                                                                                               |
|                                                          sa8775p.dtsi                                                                         |
|                                                              |                                                                                |
|                                    +-------------------------+-----------------------+                                                        |
|                                    |                         |                       |                                                        |
|                                    v                         |                       v                                                        |
|                             qcs9075-module.dtsi              |                qcs9100-module.dtsi                                             |
|                                    |                         |                       |                                                        |
|                                    v                         v                       v                                                        |
|                                  (IOT)                    (AUTO)                   (IOT)                                                      |
|                                    |                         |                       |                                                        |
|             +----------------------+                         |                       |                                                        |
|             |                      |                         |                       |                                                        |
|             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
|             |                      | |                       | |                     | |                                                      |
|             v                      v v                       v v                     v v                                                      |
|  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
|                                    |                         |                       |                                                        |
|                                    | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso  |
|                                    | |                       | |                     | |                                                      |
|                                    v v                       v v                     v v                                                      |
|                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
|                                                                                                                                               |
+-----------------------------------------------------------------------------------------------------------------------------------------------+

> > 
> > With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
> > all of which we need.
> > - sa8775p-ride.dts is auto grade Ride platform with safety feature.
> > - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
> > - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
> > 
> > Since the Ride-r3 boards are essentially Ride boards with Ethernet
> > modifications, we can convert the Ride-r3 DTS to overlays.
> How one board can be with multiple SoCs? If it is soldered, it's close
> to impossible - that's just not the same board. If it is not soldered,
> why you are not explaining it? What is Ride board? What is there? What
> can go there? How it can be used in other SoCs? Or for which SoCs? Is
> there a datasheet available?
> 

As our SoC is based on SIP card and SIP card is compatible with Ride
board, we could able to use same Ride board (which is combination of
multiple daughter cards) with multiple SIP cards.
These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC.

> You keep repeating my about SoC and I keep responding the same: don't care.
> 
> Best regards,
> Krzysztof

Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 27/02/2025 08:37, Wasim Nazir wrote:
> On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote:
>> On 15/01/2025 06:48, Wasim Nazir wrote:
>>>> The the SoC, I am asking about the board. Why each of them is for
>>>> example r3?
>>>>
>>>> So this is not sufficient explanation, nothing about the board, and
>>>> again just look Renesas and NXP.
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
>>> safety capabilities and memory map, serving different purpose.
>>> Ride & Ride-r3 are different boards based on ethernet capabilities and
>>> are compatible with all the SoCs mentioned.
>>
> 
> Hi Krzysztof,
> 
>> Compatible? What does it mean for a board?
>>
> 
> Ride board is based on multiple daughter cards (SOC-card, display,
> camera, ethernet, pcie, sensor, etc.).
> 
> The SOC is not directly soldered to Ride board, instead SOC is soldered
> on SIP (System in Package) card which can be mounted on SOC-daughter card of
> Ride board.
> 	- SoC => SIP-card => SOC-daughter-card (Ride)


So basically pretty like other designs using SoM.

> 
> Together with SIP cards and other daughter cards we are creating different
> <soc>-Ride Variants with differences in memory map & thermal mitigations.
> 
> The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the
> SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP
> cards, except an additional third party SIL-PMIC for SAIL, which is not
> present in QCS9075 Ride.

Just like every SoM

> 
> Other daughter cards remains same for <soc>-Ride variants, except
> ethernet card which is different for <soc>-Ride rev3 variants.
> 
> So the Ride board (combination of daughter cards) is same across the SIP,
> while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075.
> 
>> Third time: did you look how other vendors do it?
>>
> 
> Yes, we have reviewed other vendors. However, please feel free to share
> any specific reference you would like us to follow.
> 
> Here are few reference files we found from other vendors where similar
> tasks are performed which includes code refactoring and HW modularity:
>  - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts

That's an unexpected choice - I would rather look at dozen of SoMs for
iMX platforms.

>  - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts
>  - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi,
>    px30-engicam-px30-core-ctouch2.dts
> 
> In our case along with describing the HW, code refactoring is also done
> which might be causing confusion, but we are ready for any inputs for
> correction.

I don't understand why this was not properly described since beginning.
You had the hardware in your hands and went with incomplete or even
incorrect hardware description.

> 
> Putting this pictorial diagram for updated DT structure depicting our HW.
>  - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having
>    SoC, PMICs, Memory-map updates.
>  - qcom-ride-common.dtsi specifying ride daughter boards, here we are
>    doing code refactoring also as this is common for all ride boards.
>  - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which
>    uses 2.5G phy and can be overlayed to ride boards to get ride-r3.
>    By default ride uses 1G phy.
>  - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product
>    name. We will be changing this in next patch series.
> 
> +-----------------------------------------------------------------------------------------------------------------------------------------------+
> |                                                                                                                                               |
> |                                                          sa8775p.dtsi                                                                         |
> |                                                              |                                                                                |
> |                                    +-------------------------+-----------------------+                                                        |
> |                                    |                         |                       |                                                        |
> |                                    v                         |                       v                                                        |
> |                             qcs9075-module.dtsi              |                qcs9100-module.dtsi                                             |

So this is the SoM?

> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
> |                                    |                         |                       |                                                        |
> |             +----------------------+                         |                       |                                                        |
> |             |                      |                         |                       |                                                        |
> |             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |

Which piece of actual hardware is represented in qcom-ride-common?

> |             |                      | |                       | |                     | |                                                      |
> |             v                      v v                       v v                     v v                                                      |
> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> |                                    |                         |                       |                                                        |
> |                                    | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso  |
> |                                    | |                       | |                     | |                                                      |
> |                                    v v                       v v                     v v                                                      |
> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |

I think I gave already few times that answer: No. You cannot reference
from a module.c another .c file. You cannot reference DTS from DTS.

Strictly speaking you can, of course, but you must not. That's not how
source code is done to be manageable and readable.

> |                                                                                                                                               |
> +-----------------------------------------------------------------------------------------------------------------------------------------------+
> 
>>>
>>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
>>> all of which we need.
>>> - sa8775p-ride.dts is auto grade Ride platform with safety feature.
>>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
>>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
>>>
>>> Since the Ride-r3 boards are essentially Ride boards with Ethernet
>>> modifications, we can convert the Ride-r3 DTS to overlays.
>> How one board can be with multiple SoCs? If it is soldered, it's close
>> to impossible - that's just not the same board. If it is not soldered,
>> why you are not explaining it? What is Ride board? What is there? What
>> can go there? How it can be used in other SoCs? Or for which SoCs? Is
>> there a datasheet available?
>>
> 
> As our SoC is based on SIP card and SIP card is compatible with Ride
> board, we could able to use same Ride board (which is combination of
> multiple daughter cards) with multiple SIP cards.
> These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC.

Describe properly the hardware - if you have a module or SIP if you
decide not to use industry-standard naming (but why...), then describe
it in DTSI.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote:
> On 27/02/2025 08:37, Wasim Nazir wrote:
> > On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote:
> >> On 15/01/2025 06:48, Wasim Nazir wrote:
> >>>> The the SoC, I am asking about the board. Why each of them is for
> >>>> example r3?
> >>>>
> >>>> So this is not sufficient explanation, nothing about the board, and
> >>>> again just look Renesas and NXP.
> >>>>
> >>>
> >>> Hi Krzysztof,
> >>>
> >>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
> >>> safety capabilities and memory map, serving different purpose.
> >>> Ride & Ride-r3 are different boards based on ethernet capabilities and
> >>> are compatible with all the SoCs mentioned.
> >>
> > 
> > Hi Krzysztof,
> > 
> >> Compatible? What does it mean for a board?
> >>
> > 
> > Ride board is based on multiple daughter cards (SOC-card, display,
> > camera, ethernet, pcie, sensor, etc.).
> > 
> > The SOC is not directly soldered to Ride board, instead SOC is soldered
> > on SIP (System in Package) card which can be mounted on SOC-daughter card of
> > Ride board.
> > 	- SoC => SIP-card => SOC-daughter-card (Ride)
> 
> 
> So basically pretty like other designs using SoM.
> 
> > 
> > Together with SIP cards and other daughter cards we are creating different
> > <soc>-Ride Variants with differences in memory map & thermal mitigations.
> > 
> > The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the
> > SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP
> > cards, except an additional third party SIL-PMIC for SAIL, which is not
> > present in QCS9075 Ride.
> 
> Just like every SoM
> 
> > 
> > Other daughter cards remains same for <soc>-Ride variants, except
> > ethernet card which is different for <soc>-Ride rev3 variants.
> > 
> > So the Ride board (combination of daughter cards) is same across the SIP,
> > while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075.
> > 
> >> Third time: did you look how other vendors do it?
> >>
> > 
> > Yes, we have reviewed other vendors. However, please feel free to share
> > any specific reference you would like us to follow.
> > 
> > Here are few reference files we found from other vendors where similar
> > tasks are performed which includes code refactoring and HW modularity:
> >  - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts
> 
> That's an unexpected choice - I would rather look at dozen of SoMs for
> iMX platforms.
> 
> >  - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts
> >  - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi,
> >    px30-engicam-px30-core-ctouch2.dts
> > 
> > In our case along with describing the HW, code refactoring is also done
> > which might be causing confusion, but we are ready for any inputs for
> > correction.
> 
> I don't understand why this was not properly described since beginning.
> You had the hardware in your hands and went with incomplete or even
> incorrect hardware description.
> 
> > 
> > Putting this pictorial diagram for updated DT structure depicting our HW.
> >  - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having
> >    SoC, PMICs, Memory-map updates.
> >  - qcom-ride-common.dtsi specifying ride daughter boards, here we are
> >    doing code refactoring also as this is common for all ride boards.
> >  - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which
> >    uses 2.5G phy and can be overlayed to ride boards to get ride-r3.
> >    By default ride uses 1G phy.
> >  - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product
> >    name. We will be changing this in next patch series.
> > 
> > +-----------------------------------------------------------------------------------------------------------------------------------------------+
> > |                                                                                                                                               |
> > |                                                          sa8775p.dtsi                                                                         |
> > |                                                              |                                                                                |
> > |                                    +-------------------------+-----------------------+                                                        |
> > |                                    |                         |                       |                                                        |
> > |                                    v                         |                       v                                                        |
> > |                             qcs9075-module.dtsi              |                qcs9100-module.dtsi                                             |
> 
> So this is the SoM?

Yes this is SoM.

> 
> > |                                    |                         |                       |                                                        |
> > |                                    v                         v                       v                                                        |
> > |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
> > |                                    |                         |                       |                                                        |
> > |             +----------------------+                         |                       |                                                        |
> > |             |                      |                         |                       |                                                        |
> > |             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
> 
> Which piece of actual hardware is represented in qcom-ride-common?
> 

All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.

> > |             |                      | |                       | |                     | |                                                      |
> > |             v                      v v                       v v                     v v                                                      |
> > |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> > |                                    |                         |                       |                                                        |
> > |                                    | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso  |
> > |                                    | |                       | |                     | |                                                      |
> > |                                    v v                       v v                     v v                                                      |
> > |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> 
> I think I gave already few times that answer: No. You cannot reference
> from a module.c another .c file. You cannot reference DTS from DTS.
> 
> Strictly speaking you can, of course, but you must not. That's not how
> source code is done to be manageable and readable.

Ah the arrow is leading to confusion.

Actually we are not including dts here instead *.dtso file will be
overlayed to *-ride.dts to generate *-ride-r3.dts.

Below is the correct arrow sequence.

|  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
|                                    |                         |                       |                                                        |
|                                    +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso  |
|                                    |                         |                       |                                                        |
|                                    v                         v                       v                                                        |
|                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |

> 
> > |                                                                                                                                               |
> > +-----------------------------------------------------------------------------------------------------------------------------------------------+
> > 
> >>>
> >>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
> >>> all of which we need.
> >>> - sa8775p-ride.dts is auto grade Ride platform with safety feature.
> >>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
> >>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
> >>>
> >>> Since the Ride-r3 boards are essentially Ride boards with Ethernet
> >>> modifications, we can convert the Ride-r3 DTS to overlays.
> >> How one board can be with multiple SoCs? If it is soldered, it's close
> >> to impossible - that's just not the same board. If it is not soldered,
> >> why you are not explaining it? What is Ride board? What is there? What
> >> can go there? How it can be used in other SoCs? Or for which SoCs? Is
> >> there a datasheet available?
> >>
> > 
> > As our SoC is based on SIP card and SIP card is compatible with Ride
> > board, we could able to use same Ride board (which is combination of
> > multiple daughter cards) with multiple SIP cards.
> > These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC.
> 
> Describe properly the hardware - if you have a module or SIP if you
> decide not to use industry-standard naming (but why...), then describe
> it in DTSI.

We refer to it as ‘module’ in our datasheet, so I use the same term
here. Thanks for pointing it out; we can proceed with the SoM name.

Below is the updated diagram:
+-----------------------------------------------------------------------------------------------------------------------------------------------+
|                                                                                                                                               |
|                                                          sa8775p.dtsi                                                                         |
|                                                              |                                                                                |
|                                    +-------------------------+-----------------------+                                                        |
|                                    |                         |                       |                                                        |
|                                    v                         |                       v                                                        |
|                             qcs9075-som.dtsi                 |                qcs9100-som.dtsi                                                |
|                                    |                         |                       |                                                        |
|                                    v                         v                       v                                                        |
|                                  (IOT)                    (AUTO)                   (IOT)                                                      |
|                                    |                         |                       |                                                        |
|             +----------------------+                         |                       |                                                        |
|             |                      |                         |                       |                                                        |
|             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
|             |                      | |                       | |                     | |                                                      |
|             v                      v v                       v v                     v v                                                      |
|  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
|                                    |                         |                       |                                                        |
|                                    +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso  |
|                                    |                         |                       |                                                        |
|                                    v                         v                       v                                                        |
|                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
|                                                                                                                                               |
+-----------------------------------------------------------------------------------------------------------------------------------------------+

> 
> Best regards,
> Krzysztof

Thanks & regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Thu, Mar 06, 2025 at 01:47:15PM +0530, Wasim Nazir wrote:
> On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote:
> > On 27/02/2025 08:37, Wasim Nazir wrote:
> > > On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote:
> > >> On 15/01/2025 06:48, Wasim Nazir wrote:
> > >>>> The the SoC, I am asking about the board. Why each of them is for
> > >>>> example r3?
> > >>>>
> > >>>> So this is not sufficient explanation, nothing about the board, and
> > >>>> again just look Renesas and NXP.
> > >>>>
> > >>>
> > >>> Hi Krzysztof,
> > >>>
> > >>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
> > >>> safety capabilities and memory map, serving different purpose.
> > >>> Ride & Ride-r3 are different boards based on ethernet capabilities and
> > >>> are compatible with all the SoCs mentioned.
> > >>
> > > 
> > > Hi Krzysztof,
> > > 
> > >> Compatible? What does it mean for a board?
> > >>
> > > 
> > > Ride board is based on multiple daughter cards (SOC-card, display,
> > > camera, ethernet, pcie, sensor, etc.).
> > > 
> > > The SOC is not directly soldered to Ride board, instead SOC is soldered
> > > on SIP (System in Package) card which can be mounted on SOC-daughter card of
> > > Ride board.
> > > 	- SoC => SIP-card => SOC-daughter-card (Ride)
> > 
> > 
> > So basically pretty like other designs using SoM.
> > 
> > > 
> > > Together with SIP cards and other daughter cards we are creating different
> > > <soc>-Ride Variants with differences in memory map & thermal mitigations.
> > > 
> > > The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the
> > > SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP
> > > cards, except an additional third party SIL-PMIC for SAIL, which is not
> > > present in QCS9075 Ride.
> > 
> > Just like every SoM
> > 
> > > 
> > > Other daughter cards remains same for <soc>-Ride variants, except
> > > ethernet card which is different for <soc>-Ride rev3 variants.
> > > 
> > > So the Ride board (combination of daughter cards) is same across the SIP,
> > > while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075.
> > > 
> > >> Third time: did you look how other vendors do it?
> > >>
> > > 
> > > Yes, we have reviewed other vendors. However, please feel free to share
> > > any specific reference you would like us to follow.
> > > 
> > > Here are few reference files we found from other vendors where similar
> > > tasks are performed which includes code refactoring and HW modularity:
> > >  - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts
> > 
> > That's an unexpected choice - I would rather look at dozen of SoMs for
> > iMX platforms.
> > 
> > >  - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts
> > >  - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi,
> > >    px30-engicam-px30-core-ctouch2.dts
> > > 
> > > In our case along with describing the HW, code refactoring is also done
> > > which might be causing confusion, but we are ready for any inputs for
> > > correction.
> > 
> > I don't understand why this was not properly described since beginning.
> > You had the hardware in your hands and went with incomplete or even
> > incorrect hardware description.
> > 
> > > 
> > > Putting this pictorial diagram for updated DT structure depicting our HW.
> > >  - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having
> > >    SoC, PMICs, Memory-map updates.
> > >  - qcom-ride-common.dtsi specifying ride daughter boards, here we are
> > >    doing code refactoring also as this is common for all ride boards.
> > >  - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which
> > >    uses 2.5G phy and can be overlayed to ride boards to get ride-r3.
> > >    By default ride uses 1G phy.
> > >  - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product
> > >    name. We will be changing this in next patch series.
> > > 
> > > +-----------------------------------------------------------------------------------------------------------------------------------------------+
> > > |                                                                                                                                               |
> > > |                                                          sa8775p.dtsi                                                                         |
> > > |                                                              |                                                                                |
> > > |                                    +-------------------------+-----------------------+                                                        |
> > > |                                    |                         |                       |                                                        |
> > > |                                    v                         |                       v                                                        |
> > > |                             qcs9075-module.dtsi              |                qcs9100-module.dtsi                                             |
> > 
> > So this is the SoM?
> 
> Yes this is SoM.
> 
> > 
> > > |                                    |                         |                       |                                                        |
> > > |                                    v                         v                       v                                                        |
> > > |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
> > > |                                    |                         |                       |                                                        |
> > > |             +----------------------+                         |                       |                                                        |
> > > |             |                      |                         |                       |                                                        |
> > > |             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
> > 
> > Which piece of actual hardware is represented in qcom-ride-common?
> > 
> 
> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
> 
> > > |             |                      | |                       | |                     | |                                                      |
> > > |             v                      v v                       v v                     v v                                                      |
> > > |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> > > |                                    |                         |                       |                                                        |
> > > |                                    | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso  |
> > > |                                    | |                       | |                     | |                                                      |
> > > |                                    v v                       v v                     v v                                                      |
> > > |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> > 
> > I think I gave already few times that answer: No. You cannot reference
> > from a module.c another .c file. You cannot reference DTS from DTS.
> > 
> > Strictly speaking you can, of course, but you must not. That's not how
> > source code is done to be manageable and readable.
> 
> Ah the arrow is leading to confusion.
> 
> Actually we are not including dts here instead *.dtso file will be
> overlayed to *-ride.dts to generate *-ride-r3.dts.
> 
> Below is the correct arrow sequence.
> 
> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> |                                    |                         |                       |                                                        |
> |                                    +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso  |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> 
> > 
> > > |                                                                                                                                               |
> > > +-----------------------------------------------------------------------------------------------------------------------------------------------+
> > > 
> > >>>
> > >>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
> > >>> all of which we need.
> > >>> - sa8775p-ride.dts is auto grade Ride platform with safety feature.
> > >>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
> > >>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
> > >>>
> > >>> Since the Ride-r3 boards are essentially Ride boards with Ethernet
> > >>> modifications, we can convert the Ride-r3 DTS to overlays.
> > >> How one board can be with multiple SoCs? If it is soldered, it's close
> > >> to impossible - that's just not the same board. If it is not soldered,
> > >> why you are not explaining it? What is Ride board? What is there? What
> > >> can go there? How it can be used in other SoCs? Or for which SoCs? Is
> > >> there a datasheet available?
> > >>
> > > 
> > > As our SoC is based on SIP card and SIP card is compatible with Ride
> > > board, we could able to use same Ride board (which is combination of
> > > multiple daughter cards) with multiple SIP cards.
> > > These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC.
> > 
> > Describe properly the hardware - if you have a module or SIP if you
> > decide not to use industry-standard naming (but why...), then describe
> > it in DTSI.
> 
> We refer to it as ‘module’ in our datasheet, so I use the same term
> here. Thanks for pointing it out; we can proceed with the SoM name.
> 
> Below is the updated diagram:
> +-----------------------------------------------------------------------------------------------------------------------------------------------+
> |                                                                                                                                               |
> |                                                          sa8775p.dtsi                                                                         |
> |                                                              |                                                                                |
> |                                    +-------------------------+-----------------------+                                                        |
> |                                    |                         |                       |                                                        |
> |                                    v                         |                       v                                                        |
> |                             qcs9075-som.dtsi                 |                qcs9100-som.dtsi                                                |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
> |                                    |                         |                       |                                                        |
> |             +----------------------+                         |                       |                                                        |
> |             |                      |                         |                       |                                                        |
> |             |                      | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi           |
> |             |                      | |                       | |                     | |                                                      |
> |             v                      v v                       v v                     v v                                                      |
> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> |                                    |                         |                       |                                                        |
> |                                    +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> |                                                                                                                                               |
> +-----------------------------------------------------------------------------------------------------------------------------------------------+
> 

Updating typo: qcom-ride-* changed to sa8775p-ride-*.

> > 
> > Best regards,
> > Krzysztof
> 
> Thanks & regards,
> Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 06/03/2025 09:25, Wasim Nazir wrote:
>> +-----------------------------------------------------------------------------------------------------------------------------------------------+
>> |                                                                                                                                               |
>> |                                                          sa8775p.dtsi                                                                         |
>> |                                                              |                                                                                |
>> |                                    +-------------------------+-----------------------+                                                        |
>> |                                    |                         |                       |                                                        |
>> |                                    v                         |                       v                                                        |
>> |                             qcs9075-som.dtsi                 |                qcs9100-som.dtsi                                                |
>> |                                    |                         |                       |                                                        |
>> |                                    v                         v                       v                                                        |
>> |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
>> |                                    |                         |                       |                                                        |
>> |             +----------------------+                         |                       |                                                        |
>> |             |                      |                         |                       |                                                        |
>> |             |                      | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi           |


There is no ride-common hardware. If there is, send us any proof of its
existence. all your statements here show you want to create some
structure because you like it. I don't think you get my questions. You
painted diagram of DTS, not hardware.

We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
and show us the hardware.

I have been asking it for two months now and it is just waste of time to
keep talking the same.


>> |             |                      | |                       | |                     | |                                                      |
>> |             v                      v v                       v v                     v v                                                      |
>> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
>> |                                    |                         |                       |                                                        |
>> |                                    +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |

How does "sa8775p-ride-ethernet-aqr115c" hardware look like?

>> |                                    |                         |                       |                                                        |
>> |                                    v                         v                       v                                                        |
>> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
>> |                                                                                                                                               |
>> +-----------------------------------------------------------------------------------------------------------------------------------------------+
>>
> 
> Updating typo: qcom-ride-* changed to sa8775p-ride-*.
> 

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

Hi Krzysztof,

> >>
> >> Which piece of actual hardware is represented in qcom-ride-common?
> >>
> > 
> > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
> 
> No, I asked about the name of the hardware, datasheet, ID or picture.
> Common DTSI represents somoething, not just because you wanted to add
> something you had in downstream.
> 

Currently we don't have any datasheet or document which is publicly
available, so I will try my best to describe our HW.

Ride is a modular hardware system with several smaller daughter cards
connected to single backplane board and each daughter card is stacked on
top of each other. I will try to explain each daughter card with HW
components and how it is connected to construct the ride-hw.

Backplane board:
  - It contains an MCU (Aurix TC397), CAN/LIN transceiver,
	Audio/GNSS/IMU-I2C signals, Fan header
  - It holds & connects all the daughter cards.

SoC card:
  - It contains:
    - SoM:
      - One of QCS9075M/QCS9100M/QAM8775p SoM.
	  - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
		with DDR & PMICs.
      - Each SoM can be mounted to same SoC-daughter card of ride-hw.
    - In addition to SoM, it also has
      - 4x UART, 2x USB 3.1 & 1x USB 2.0
      - Memory: 1x OSPI, 2x UFS-3.1
      - Debug: JTAG/QDSS header
      - PCIe0, PCIe1 & Display signals
      - Reset button
  - It is connected to backplain board via B2B connector.

Display card:
  - It contains:
    - 4 eDP ports & 2 DSI-DP bridge
    - I2C GPIO expander & I2C switch
  - It is connected to SoC-card via B2B connector.

Camera card:
  - It contains:
    - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
    - Total upto 16 Cameras ports are supported.
  - It is connected to backplain board via B2B connector.

Ethernet card:
  - There are two variants of ethernet card each with different
	capabilities:
    - [Ethernet-v1] card contains:
      - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
	  - Total 4 phy supported, only 2 phy are enabled and it is used in
		ride.
    - [Ethernet-v2] card contains:
	  - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
		MAC+PHY controller
	  - Total 5 phy supported, only 2 phy are enabled and it is used in
		ride-r3.
  - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
	via B2B connector.

PCIe card:
  - It contains:
    - PCIe connections to SoC-card
	- NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
	  GNSS module
  - It is connected to backplain board via B2B connector & PCIe signals are
	connected to SoC card via flyover cables.

Sensor Card:
  - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
	are communicating via I2C
  - It is connected to backplain board via B2B connector.

Front panel card:
  - It does not contain any active circuitry, only ports are available
    - Audio-in/out ports
    - USB hub ports
    - CAN/LIN ports
    - 12V power off switch
  - It is connected to backplain board via ribbon cable.

> 
> > 

> >> |             |                      | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi           |
> 
> 
> There is no ride-common hardware. If there is, send us any proof of its
> existence. all your statements here show you want to create some
> structure because you like it. I don't think you get my questions. You
> painted diagram of DTS, not hardware.
> 
> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
> and show us the hardware.
> 

Considering outlined h/w description, following are ride configuration
variation each platform supporting:

Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;
And between ride & ride-r3 ethernet is changing.
Excluding these differences all other cards i.e SoC, display, camera, PCIe,
sensor, front & backplain are same and are refactored in ride-common.
If any variant of these cards comes up in future we need to refactor
ride-common accordingly. I will try to outline this as clearly as possible
in next commit log.

Considering current outlines of all daughter cards, following defines
ride/ride-r3 variant boards:
  - sa8775p ride    : QAM8775p SoM + [Ethernet-v1] + other daughter cards
  - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
  - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
  - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards

Since we don't have a document yet which formally describes
qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
this particular variant in next patch series and re-send after complete
documentation is available.

> > Actually we are not including dts here instead *.dtso file will be
> > overlayed to *-ride.dts to generate *-ride-r3.dts.
> > 
> > Below is the correct arrow sequence.
> 
> And the overlay represents what exactly? Different board? No, that's not
> how overlays should be used.
> 
> You have different board, you have different DTS.
> 

No the overlay is not a different ride board. This overlay represents
[Ethernet-v2] card which is different than [Ethernet-v1] card.

We thought of using overlay as otherwise we have to create separate board
DTS to support [Ethernet-v2] cards.

> 
> > 


> >> |                                    +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |
> 
> How does "sa8775p-ride-ethernet-aqr115c" hardware look like?
> 

Here sa8775p-ride-ethernet-aqr115c.dtso is representing [Ethernet-v2] card.

> 
> Several companies solved it - most of NXP vendors, many Renesas etc. I
> really do not get why this needs so much talk and you cannot learn from
> their architecture how SoM should be represented.
> 

Our SoM is separate HW which is reusable in ride-hw. Can you share more
details on what we can improve here?


Thanks & regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 20/03/2025 12:45, Wasim Nazir wrote:
> Hi Krzysztof,
> 
>>>>
>>>> Which piece of actual hardware is represented in qcom-ride-common?
>>>>
>>>
>>> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
>>
>> No, I asked about the name of the hardware, datasheet, ID or picture.
>> Common DTSI represents somoething, not just because you wanted to add
>> something you had in downstream.
>>
> 
> Currently we don't have any datasheet or document which is publicly
> available, so I will try my best to describe our HW.
> 
> Ride is a modular hardware system with several smaller daughter cards
> connected to single backplane board and each daughter card is stacked on
> top of each other. I will try to explain each daughter card with HW
> components and how it is connected to construct the ride-hw.
> 
> Backplane board:
>   - It contains an MCU (Aurix TC397), CAN/LIN transceiver,
> 	Audio/GNSS/IMU-I2C signals, Fan header
>   - It holds & connects all the daughter cards.
> 
> SoC card:
>   - It contains:
>     - SoM:
>       - One of QCS9075M/QCS9100M/QAM8775p SoM.
> 	  - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
> 		with DDR & PMICs.
>       - Each SoM can be mounted to same SoC-daughter card of ride-hw.
>     - In addition to SoM, it also has
>       - 4x UART, 2x USB 3.1 & 1x USB 2.0
>       - Memory: 1x OSPI, 2x UFS-3.1
>       - Debug: JTAG/QDSS header
>       - PCIe0, PCIe1 & Display signals
>       - Reset button
>   - It is connected to backplain board via B2B connector.
> 
> Display card:
>   - It contains:
>     - 4 eDP ports & 2 DSI-DP bridge
>     - I2C GPIO expander & I2C switch
>   - It is connected to SoC-card via B2B connector.
> 
> Camera card:
>   - It contains:
>     - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
>     - Total upto 16 Cameras ports are supported.
>   - It is connected to backplain board via B2B connector.
> 
> Ethernet card:
>   - There are two variants of ethernet card each with different
> 	capabilities:
>     - [Ethernet-v1] card contains:
>       - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
> 	  - Total 4 phy supported, only 2 phy are enabled and it is used in
> 		ride.
>     - [Ethernet-v2] card contains:
> 	  - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
> 		MAC+PHY controller
> 	  - Total 5 phy supported, only 2 phy are enabled and it is used in
> 		ride-r3.
>   - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
> 	via B2B connector.
> 
> PCIe card:
>   - It contains:
>     - PCIe connections to SoC-card
> 	- NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
> 	  GNSS module
>   - It is connected to backplain board via B2B connector & PCIe signals are
> 	connected to SoC card via flyover cables.
> 
> Sensor Card:
>   - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
> 	are communicating via I2C
>   - It is connected to backplain board via B2B connector.
> 
> Front panel card:
>   - It does not contain any active circuitry, only ports are available
>     - Audio-in/out ports
>     - USB hub ports
>     - CAN/LIN ports
>     - 12V power off switch
>   - It is connected to backplain board via ribbon cable.
> 
>>
>>>
> 
>>>> |             |                      | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi           |
>>
>>
>> There is no ride-common hardware. If there is, send us any proof of its
>> existence. all your statements here show you want to create some
>> structure because you like it. I don't think you get my questions. You
>> painted diagram of DTS, not hardware.
>>
>> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
>> and show us the hardware.
>>
> 
> Considering outlined h/w description, following are ride configuration
> variation each platform supporting:
> 
> Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;

Define these as SoMs then.

> And between ride & ride-r3 ethernet is changing.

Different ethernet cards can be also represented as cards - their own
DTSI. But there is no soc-card with one or other ethernet, so do not
create fake structure just because downstream had it.


> Excluding these differences all other cards i.e SoC, display, camera, PCIe,
> sensor, front & backplain are same and are refactored in ride-common.
> If any variant of these cards comes up in future we need to refactor
> ride-common accordingly. I will try to outline this as clearly as possible
> in next commit log.
> 
> Considering current outlines of all daughter cards, following defines
> ride/ride-r3 variant boards:
>   - sa8775p ride    : QAM8775p SoM + [Ethernet-v1] + other daughter cards
>   - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
>   - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
>   - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards
> 
> Since we don't have a document yet which formally describes
> qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
> this particular variant in next patch series and re-send after complete
> documentation is available.
> 
>>> Actually we are not including dts here instead *.dtso file will be
>>> overlayed to *-ride.dts to generate *-ride-r3.dts.
>>>
>>> Below is the correct arrow sequence.
>>
>> And the overlay represents what exactly? Different board? No, that's not
>> how overlays should be used.
>>
>> You have different board, you have different DTS.
>>
> 
> No the overlay is not a different ride board. This overlay represents
> [Ethernet-v2] card which is different than [Ethernet-v1] card.

Different cards is not an overlay. Overlay is for added cards, but you
replace here the card.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Sat, Mar 29, 2025 at 05:48:00AM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2025 12:45, Wasim Nazir wrote:
> > Hi Krzysztof,
> > 
> >>>>
> >>>> Which piece of actual hardware is represented in qcom-ride-common?
> >>>>
> >>>
> >>> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
> >>
> >> No, I asked about the name of the hardware, datasheet, ID or picture.
> >> Common DTSI represents somoething, not just because you wanted to add
> >> something you had in downstream.
> >>
> > 
> > Currently we don't have any datasheet or document which is publicly
> > available, so I will try my best to describe our HW.
> > 
> > Ride is a modular hardware system with several smaller daughter cards
> > connected to single backplane board and each daughter card is stacked on
> > top of each other. I will try to explain each daughter card with HW
> > components and how it is connected to construct the ride-hw.
> > 
> > Backplane board:
> >   - It contains an MCU (Aurix TC397), CAN/LIN transceiver,
> > 	Audio/GNSS/IMU-I2C signals, Fan header
> >   - It holds & connects all the daughter cards.
> > 
> > SoC card:
> >   - It contains:
> >     - SoM:
> >       - One of QCS9075M/QCS9100M/QAM8775p SoM.
> > 	  - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
> > 		with DDR & PMICs.
> >       - Each SoM can be mounted to same SoC-daughter card of ride-hw.
> >     - In addition to SoM, it also has
> >       - 4x UART, 2x USB 3.1 & 1x USB 2.0
> >       - Memory: 1x OSPI, 2x UFS-3.1
> >       - Debug: JTAG/QDSS header
> >       - PCIe0, PCIe1 & Display signals
> >       - Reset button
> >   - It is connected to backplain board via B2B connector.
> > 
> > Display card:
> >   - It contains:
> >     - 4 eDP ports & 2 DSI-DP bridge
> >     - I2C GPIO expander & I2C switch
> >   - It is connected to SoC-card via B2B connector.
> > 
> > Camera card:
> >   - It contains:
> >     - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
> >     - Total upto 16 Cameras ports are supported.
> >   - It is connected to backplain board via B2B connector.
> > 
> > Ethernet card:
> >   - There are two variants of ethernet card each with different
> > 	capabilities:
> >     - [Ethernet-v1] card contains:
> >       - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
> > 	  - Total 4 phy supported, only 2 phy are enabled and it is used in
> > 		ride.
> >     - [Ethernet-v2] card contains:
> > 	  - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
> > 		MAC+PHY controller
> > 	  - Total 5 phy supported, only 2 phy are enabled and it is used in
> > 		ride-r3.
> >   - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
> > 	via B2B connector.
> > 
> > PCIe card:
> >   - It contains:
> >     - PCIe connections to SoC-card
> > 	- NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
> > 	  GNSS module
> >   - It is connected to backplain board via B2B connector & PCIe signals are
> > 	connected to SoC card via flyover cables.
> > 
> > Sensor Card:
> >   - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
> > 	are communicating via I2C
> >   - It is connected to backplain board via B2B connector.
> > 
> > Front panel card:
> >   - It does not contain any active circuitry, only ports are available
> >     - Audio-in/out ports
> >     - USB hub ports
> >     - CAN/LIN ports
> >     - 12V power off switch
> >   - It is connected to backplain board via ribbon cable.
> > 
> >>
> >>>
> > 
> >>>> |             |                      | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi           |
> >>
> >>
> >> There is no ride-common hardware. If there is, send us any proof of its
> >> existence. all your statements here show you want to create some
> >> structure because you like it. I don't think you get my questions. You
> >> painted diagram of DTS, not hardware.
> >>
> >> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
> >> and show us the hardware.
> >>
> > 
> > Considering outlined h/w description, following are ride configuration
> > variation each platform supporting:
> > 
> > Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;
> 
> Define these as SoMs then.

sure

> 
> > And between ride & ride-r3 ethernet is changing.
> 
> Different ethernet cards can be also represented as cards - their own
> DTSI. But there is no soc-card with one or other ethernet, so do not
> create fake structure just because downstream had it.
> 

Ok, will proceed with dtsi for v1/v2 ethernet cards and use it for ride &
ride-r3 respectively.

> 
> > Excluding these differences all other cards i.e SoC, display, camera, PCIe,
> > sensor, front & backplain are same and are refactored in ride-common.
> > If any variant of these cards comes up in future we need to refactor
> > ride-common accordingly. I will try to outline this as clearly as possible
> > in next commit log.
> > 
> > Considering current outlines of all daughter cards, following defines
> > ride/ride-r3 variant boards:
> >   - sa8775p ride    : QAM8775p SoM + [Ethernet-v1] + other daughter cards
> >   - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
> >   - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
> >   - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards
> > 
> > Since we don't have a document yet which formally describes
> > qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
> > this particular variant in next patch series and re-send after complete
> > documentation is available.
> > 
> >>> Actually we are not including dts here instead *.dtso file will be
> >>> overlayed to *-ride.dts to generate *-ride-r3.dts.
> >>>
> >>> Below is the correct arrow sequence.
> >>
> >> And the overlay represents what exactly? Different board? No, that's not
> >> how overlays should be used.
> >>
> >> You have different board, you have different DTS.
> >>
> > 
> > No the overlay is not a different ride board. This overlay represents
> > [Ethernet-v2] card which is different than [Ethernet-v1] card.
> 
> Different cards is not an overlay. Overlay is for added cards, but you
> replace here the card.
> 

Understood, will proceed with dtsi way of adding ethernet cards for
ride & ride-r3 boards.

>
>

Based on current understanding, here is the final structure for the dts
& dtsi, representing all variant of boards.

Ethernet cards are represented using dtsi as:
  - [Ethernet-v1] card: sa8775p-ride-ethernet-88ea1512.dtsi
  - [Ethernet-v2] card: sa8775p-ride-ethernet-aqr115c.dtsi

+-------------------------------------------------------------------------------------------------------------------------------------------------------+
|                                                                                                                                                       |
|                                                           sa8775p.dtsi                                                                                |
|                                                                 |                                                                                     |
|                                       +-------------------------+-----------------------+                                                             |
|                                       |                         |                       |                                                             |
|                                       v                         |                       v                                                             |
|                                qcs9075-som.dtsi         qam8775p-som.dtsi        qcs9100-som.dtsi                                                     |
|                                       |                         |                       |                                                             |
|                                       v                         v                       v                                                             |
|                                     (IOT)                    (AUTO)                   (IOT)                                                           |
|                                       |                         |                       |                                                             |
|             +-------------------------+                         |                       |                                                             |
|             |                         |                         |                       |                                                             |
|             |                         | +-------------------------+-----------------------+---------------< sa8775p-ride-ethernet-88ea1512.dtsi       |
|             |                         | |                       | |                     | |                                                           |
|             |                         | | +-------------------------+-----------------------+----------+--< sa8775p-ride-common.dtsi                  |
|             |                         | | |                     | | |                   | | |          |                                              |
|             |                         | | |          +----------+ | |                   | | |          |                                              |
|             |                         | | |          |          | | |                   | | |          |                                              |
|             v                         v v v          |          v v v                   v v v          |                                              |
|  qcs9075-iq-9075-evk.dts         qcs9075-ride.dts    |     sa8775p-ride.dts        qcs9100-ride.dts    |                                              |
|                                                      |                                                 |                                              |
|                                                      | +-----------------------------------------------+                                              |
|                                                      | |                                                                                              |
|                                                      | | +------------------------------------------------< sa8775p-ride-ethernet-aqr115c.dtsi        |
|                                                      | | |                                                                                            |
|                                                      v v v                                                                                            |
|                                              sa8775p-ride-r3.dts                                                                                      |
|                                                                                                                                                       |
+-------------------------------------------------------------------------------------------------------------------------------------------------------+

Please let us know if we can proceed with the change.


Thanks & regards,
Wasim

> Best regards,
> Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Krzysztof Kozlowski]

On 06/03/2025 09:17, Wasim Nazir wrote:
> On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote:
>> On 27/02/2025 08:37, Wasim Nazir wrote:
>>> On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote:
>>>> On 15/01/2025 06:48, Wasim Nazir wrote:
>>>>>> The the SoC, I am asking about the board. Why each of them is for
>>>>>> example r3?
>>>>>>
>>>>>> So this is not sufficient explanation, nothing about the board, and
>>>>>> again just look Renesas and NXP.
>>>>>>
>>>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
>>>>> safety capabilities and memory map, serving different purpose.
>>>>> Ride & Ride-r3 are different boards based on ethernet capabilities and
>>>>> are compatible with all the SoCs mentioned.
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>>> Compatible? What does it mean for a board?
>>>>
>>>
>>> Ride board is based on multiple daughter cards (SOC-card, display,
>>> camera, ethernet, pcie, sensor, etc.).
>>>
>>> The SOC is not directly soldered to Ride board, instead SOC is soldered
>>> on SIP (System in Package) card which can be mounted on SOC-daughter card of
>>> Ride board.
>>> 	- SoC => SIP-card => SOC-daughter-card (Ride)
>>
>>
>> So basically pretty like other designs using SoM.
>>
>>>
>>> Together with SIP cards and other daughter cards we are creating different
>>> <soc>-Ride Variants with differences in memory map & thermal mitigations.
>>>
>>> The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the
>>> SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP
>>> cards, except an additional third party SIL-PMIC for SAIL, which is not
>>> present in QCS9075 Ride.
>>
>> Just like every SoM
>>
>>>
>>> Other daughter cards remains same for <soc>-Ride variants, except
>>> ethernet card which is different for <soc>-Ride rev3 variants.
>>>
>>> So the Ride board (combination of daughter cards) is same across the SIP,
>>> while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075.
>>>
>>>> Third time: did you look how other vendors do it?
>>>>
>>>
>>> Yes, we have reviewed other vendors. However, please feel free to share
>>> any specific reference you would like us to follow.
>>>
>>> Here are few reference files we found from other vendors where similar
>>> tasks are performed which includes code refactoring and HW modularity:
>>>  - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts
>>
>> That's an unexpected choice - I would rather look at dozen of SoMs for
>> iMX platforms.
>>
>>>  - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts
>>>  - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi,
>>>    px30-engicam-px30-core-ctouch2.dts
>>>
>>> In our case along with describing the HW, code refactoring is also done
>>> which might be causing confusion, but we are ready for any inputs for
>>> correction.
>>
>> I don't understand why this was not properly described since beginning.
>> You had the hardware in your hands and went with incomplete or even
>> incorrect hardware description.
>>
>>>
>>> Putting this pictorial diagram for updated DT structure depicting our HW.
>>>  - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having
>>>    SoC, PMICs, Memory-map updates.
>>>  - qcom-ride-common.dtsi specifying ride daughter boards, here we are
>>>    doing code refactoring also as this is common for all ride boards.
>>>  - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which
>>>    uses 2.5G phy and can be overlayed to ride boards to get ride-r3.
>>>    By default ride uses 1G phy.
>>>  - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product
>>>    name. We will be changing this in next patch series.
>>>
>>> +-----------------------------------------------------------------------------------------------------------------------------------------------+
>>> |                                                                                                                                               |
>>> |                                                          sa8775p.dtsi                                                                         |
>>> |                                                              |                                                                                |
>>> |                                    +-------------------------+-----------------------+                                                        |
>>> |                                    |                         |                       |                                                        |
>>> |                                    v                         |                       v                                                        |
>>> |                             qcs9075-module.dtsi              |                qcs9100-module.dtsi                                             |
>>
>> So this is the SoM?
> 
> Yes this is SoM.
> 
>>
>>> |                                    |                         |                       |                                                        |
>>> |                                    v                         v                       v                                                        |
>>> |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
>>> |                                    |                         |                       |                                                        |
>>> |             +----------------------+                         |                       |                                                        |
>>> |             |                      |                         |                       |                                                        |
>>> |             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
>>
>> Which piece of actual hardware is represented in qcom-ride-common?
>>
> 
> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.

No, I asked about the name of the hardware, datasheet, ID or picture.
Common DTSI represents somoething, not just because you wanted to add
something you had in downstream.


> 
>>> |             |                      | |                       | |                     | |                                                      |
>>> |             v                      v v                       v v                     v v                                                      |
>>> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
>>> |                                    |                         |                       |                                                        |
>>> |                                    | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso  |
>>> |                                    | |                       | |                     | |                                                      |
>>> |                                    v v                       v v                     v v                                                      |
>>> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
>>
>> I think I gave already few times that answer: No. You cannot reference
>> from a module.c another .c file. You cannot reference DTS from DTS.
>>
>> Strictly speaking you can, of course, but you must not. That's not how
>> source code is done to be manageable and readable.
> 
> Ah the arrow is leading to confusion.
> 
> Actually we are not including dts here instead *.dtso file will be
> overlayed to *-ride.dts to generate *-ride-r3.dts.
> 
> Below is the correct arrow sequence.

And the overlay represents what exactly? Different board? No, that's not
how overlays should be used.

You have different board, you have different DTS.


> 
> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> |                                    |                         |                       |                                                        |
> |                                    +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso  |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> 
>>
>>> |                                                                                                                                               |
>>> +-----------------------------------------------------------------------------------------------------------------------------------------------+
>>>
>>>>>
>>>>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
>>>>> all of which we need.
>>>>> - sa8775p-ride.dts is auto grade Ride platform with safety feature.
>>>>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature.
>>>>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature.
>>>>>
>>>>> Since the Ride-r3 boards are essentially Ride boards with Ethernet
>>>>> modifications, we can convert the Ride-r3 DTS to overlays.
>>>> How one board can be with multiple SoCs? If it is soldered, it's close
>>>> to impossible - that's just not the same board. If it is not soldered,
>>>> why you are not explaining it? What is Ride board? What is there? What
>>>> can go there? How it can be used in other SoCs? Or for which SoCs? Is
>>>> there a datasheet available?
>>>>
>>>
>>> As our SoC is based on SIP card and SIP card is compatible with Ride
>>> board, we could able to use same Ride board (which is combination of
>>> multiple daughter cards) with multiple SIP cards.
>>> These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC.
>>
>> Describe properly the hardware - if you have a module or SIP if you
>> decide not to use industry-standard naming (but why...), then describe
>> it in DTSI.
> 
> We refer to it as ‘module’ in our datasheet, so I use the same term
> here. Thanks for pointing it out; we can proceed with the SoM name.
> 
> Below is the updated diagram:
> +-----------------------------------------------------------------------------------------------------------------------------------------------+
> |                                                                                                                                               |
> |                                                          sa8775p.dtsi                                                                         |
> |                                                              |                                                                                |
> |                                    +-------------------------+-----------------------+                                                        |
> |                                    |                         |                       |                                                        |
> |                                    v                         |                       v                                                        |
> |                             qcs9075-som.dtsi                 |                qcs9100-som.dtsi                                                |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                                  (IOT)                    (AUTO)                   (IOT)                                                      |
> |                                    |                         |                       |                                                        |
> |             +----------------------+                         |                       |                                                        |
> |             |                      |                         |                       |                                                        |
> |             |                      | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi            |
> |             |                      | |                       | |                     | |                                                      |
> |             v                      v v                       v v                     v v                                                      |
> |  qcs9075-iq-9075-evk.dts     qcs9075-ride.dts         sa8775p-ride.dts         qcs9100-ride.dts                                               |
> |                                    |                         |                       |                                                        |
> |                                    +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso  |
> |                                    |                         |                       |                                                        |
> |                                    v                         v                       v                                                        |
> |                             qcs9075-ride-r3.dts      sa8775p-ride-r3.dts      qcs9100-ride-r3.dts                                             |
> |                                                                                                                                               |
> +-----------------------------------------------------------------------------------------------------------------------------------------------+


Several companies solved it - most of NXP vendors, many Renesas etc. I
really do not get why this needs so much talk and you cannot learn from
their architecture how SoM should be represented.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Fri, Jan 03, 2025 at 09:58:40PM +0200, Dmitry Baryshkov wrote:
> On Sat, Jan 04, 2025 at 12:29:07AM +0530, Wasim Nazir wrote:
> > On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > > > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > > > > 
> > > > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > > > management.
> > > > > > > > 
> > > > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > > > > 
> > > > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > > > include corresponding SA8775P files.
> > > > > > > 
> > > > > > > This is not ideal for the following reasons:
> > > > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > > > >   lead to mistakes.
> > > > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > > > >   to issues being patches in the one board file, but not in the other
> > > > > > >   file.
> > > > > > > 
> > > > > > > If there are any reasons why you want to follow this approach, they must
> > > > > > > be a part of the commit message.
> > > > > > > 
> > > > > > 
> > > > > > Hi Dmitry,
> > > > > > 
> > > > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > > > > 
> > > > > > Please let us know how to proceed further on this.
> > > > > 
> > > > > Krzysztof asked you to include DTSI files instead of including DTS
> > > > > files. Hope this helps.
> > > > 
> > > > Are you suggesting that we should also modify the 9100-ride files to
> > > > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > > > However, this would result in the duplication of Ethernet nodes in all
> > > > the ride board files. Would that be acceptable?
> > > 
> > > git mv foo.dts foo.dtsi
> > > echo '#include "foo.dtsi"' > foo.dts
> > > git add foo.dts
> > > git commit
> > > 
> > 
> > We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> > they represent different platforms. In patch [1], we included these DTS
> > files to reuse the common hardware nodes.
> > 
> > Could you please advise on how we should proceed with the following
> > approaches?
> > 
> > a) Previous approach [1]:
> > Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> > platform DTS, similar to the qcs9100-ride platform DTS. This approach
> > avoids duplicating Ethernet nodes and maintains uniformity. However, it
> > involves including the DTS file directly.
> > 
> > b) Current suggestion:
> > Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> > modify the qcs9100-ride platform DTS files to maintain uniformity. This
> > approach results in duplicating Ethernet nodes.
> > 
> > Please let us know your recommendation to finalize the DT structure.
> 
> sa8775p.dtsi
> `__sa8775p-ride.dtsi
>    `__sa8775p-ride-r2.dtsi
>       `__sa8775p-ride.dts
>       `__qcs9100-ride.dts
>       `__qcs9075-ride.dts
>    `__sa8775p-ride-r3.dtsi
>       `__sa8775p-ride-r3.dts
>       `__qcs9100-ride-r3.dts
>       `__qcs9075-ride-r3.dts

Thanks Dmitry, we need slight modification to the above structure as
we don't have any ride-r2 boards, so we want to go ahead with this structure:

sa8775p.dtsi
`__sa8775p-ride-common.dtsi
   `__sa8775p-ride.dtsi
      `__sa8775p-ride.dts
      `__qcs9100-ride.dts
      `__qcs9075-ride.dts
   `__sa8775p-ride-r3.dtsi
      `__sa8775p-ride-r3.dts
      `__qcs9100-ride-r3.dts
      `__qcs9075-ride-r3.dts

> 
> > 
> > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > > > > 
> > > > > > > > 
> > > > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > > > ---
> > > > > > > >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> > > > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > > > >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> > > > > > > >  3 files changed, 94 insertions(+)
> > > > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > > 
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > > > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > > > > > > > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> > > > > > > >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..d9a8956d3a76
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > > @@ -0,0 +1,46 @@
> > > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > +/*
> > > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > > + */
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > > > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&ethernet0 {
> > > > > > > > +	phy-mode = "2500base-x";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&ethernet1 {
> > > > > > > > +	phy-mode = "2500base-x";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mdio {
> > > > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > > > +	#address-cells = <1>;
> > > > > > > > +	#size-cells = <0>;
> > > > > > > > +
> > > > > > > > +	sgmii_phy0: phy@8 {
> > > > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > > +		reg = <0x8>;
> > > > > > > > +		device_type = "ethernet-phy";
> > > > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > > +		reset-assert-us = <11000>;
> > > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > > +	};
> > > > > > > > +
> > > > > > > > +	sgmii_phy1: phy@0 {
> > > > > > > > +		compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > > +		reg = <0x0>;
> > > > > > > > +		device_type = "ethernet-phy";
> > > > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > > +		reset-assert-us = <11000>;
> > > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > > +	};
> > > > > > > > +};
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..3b524359a72d
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > > @@ -0,0 +1,46 @@
> > > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > +/*
> > > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > > + */
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > > > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&ethernet0 {
> > > > > > > > +	phy-mode = "sgmii";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&ethernet1 {
> > > > > > > > +	phy-mode = "sgmii";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mdio {
> > > > > > > > +	compatible = "snps,dwmac-mdio";
> > > > > > > > +	#address-cells = <1>;
> > > > > > > > +	#size-cells = <0>;
> > > > > > > > +
> > > > > > > > +	sgmii_phy0: phy@8 {
> > > > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > > +		reg = <0x8>;
> > > > > > > > +		device_type = "ethernet-phy";
> > > > > > > > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > > +		reset-assert-us = <11000>;
> > > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > > +	};
> > > > > > > > +
> > > > > > > > +	sgmii_phy1: phy@a {
> > > > > > > > +		compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > > +		reg = <0xa>;
> > > > > > > > +		device_type = "ethernet-phy";
> > > > > > > > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > > +		reset-assert-us = <11000>;
> > > > > > > > +		reset-deassert-us = <70000>;
> > > > > > > > +	};
> > > > > > > > +};
> > > > > > > > --
> > > > > > > > 2.47.0
> > > > > > > > 
> > > > > > > 
> > > > > > > -- 
> > > > > > > With best wishes
> > > > > > > Dmitry
> > > > > > 
> > > > > > 
> > > > > > Thanks & Regards,
> > > > > > Wasim
> > > > > 
> > > > > -- 
> > > > > With best wishes
> > > > > Dmitry
> > > > 
> > > > 
> > > > Thanks & Regards,
> > > > Wasim
> > > 
> > > -- 
> > > With best wishes
> > > Dmitry
> > 
> > Thanks & Regards,
> > Wasim
> 
> -- 
> With best wishes
> Dmitry

Thanks & Regards,
Wasim

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Bjorn Andersson]

On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
> 
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
> 
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> 

This commit message is written under the assumption that the reader
first reads the patch, to determine what QCS9075 subtracts features
from.

Please describe what the QCS9075 Ride and Ride R3 are, if it's just a
variant of QCS9100 without SAIL, write that - and if that is all the
difference, then Dmitry's request makes total sense.


Also, subject prefix doesn't match upstream style. Prefix with the
subsystem/platform/device and avoid "for XYZ". See "git log" on a few
of the other files to see how it should look like.

Thanks,
Bjorn

> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile            |  2 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
>  3 files changed, 94 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@0 {
> +		compatible = "ethernet-phy-id31c3.1c33";
> +		reg = <0x0>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +&ethernet0 {
> +	phy-mode = "sgmii";
> +};
> +
> +&ethernet1 {
> +	phy-mode = "sgmii";
> +};
> +
> +&mdio {
> +	compatible = "snps,dwmac-mdio";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	sgmii_phy0: phy@8 {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0x8>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +
> +	sgmii_phy1: phy@a {
> +		compatible = "ethernet-phy-id0141.0dd4";
> +		reg = <0xa>;
> +		device_type = "ethernet-phy";
> +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> +		reset-assert-us = <11000>;
> +		reset-deassert-us = <70000>;
> +	};
> +};
> --
> 2.47.0
> 

Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3

[Wasim Nazir]

On Mon, Jan 06, 2025 at 05:59:01PM -0600, Bjorn Andersson wrote:
> On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > 
> > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > subsystem which is available in QCS9100, and it affects thermal
> > management.
> > 
> > Also, between ride and ride-r3 ethernet phy is different.
> > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > 
> 
> This commit message is written under the assumption that the reader
> first reads the patch, to determine what QCS9075 subtracts features
> from.
> 
> Please describe what the QCS9075 Ride and Ride R3 are, if it's just a
> variant of QCS9100 without SAIL, write that - and if that is all the
> difference, then Dmitry's request makes total sense.
> 

9075 is not derived from 9100 but from 8775, though difference between
9075 & 9100 is only SAIL. And in commit message I have tried to add
details to differentiate between 9075 & 9100 and most importantly to
highlight why we need sperate DT for 9075.
Will add more details in commit message instead of adding it in
cover-letter.

Also, I am convinced to proceed with Dmitry's approach to structure the
DT.

> 
> Also, subject prefix doesn't match upstream style. Prefix with the
> subsystem/platform/device and avoid "for XYZ". See "git log" on a few
> of the other files to see how it should look like.

Sure will change this accordingly.

> 
> Thanks,
> Bjorn
> 
> > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > ---
> >  arch/arm64/boot/dts/qcom/Makefile            |  2 +
> >  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/qcs9075-ride.dts    | 46 ++++++++++++++++++++
> >  3 files changed, 94 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> >  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 78613a1bd34a..41cb2bbd3472 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-rb8.dtb
> > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride.dtb
> > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs9075-ride-r3.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
> >  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > new file mode 100644
> > index 000000000000..d9a8956d3a76
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > +	compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +&ethernet0 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&ethernet1 {
> > +	phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > +	compatible = "snps,dwmac-mdio";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	sgmii_phy0: phy@8 {
> > +		compatible = "ethernet-phy-id31c3.1c33";
> > +		reg = <0x8>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +
> > +	sgmii_phy1: phy@0 {
> > +		compatible = "ethernet-phy-id31c3.1c33";
> > +		reg = <0x0>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > new file mode 100644
> > index 000000000000..3b524359a72d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > +	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > +	compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +&ethernet0 {
> > +	phy-mode = "sgmii";
> > +};
> > +
> > +&ethernet1 {
> > +	phy-mode = "sgmii";
> > +};
> > +
> > +&mdio {
> > +	compatible = "snps,dwmac-mdio";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	sgmii_phy0: phy@8 {
> > +		compatible = "ethernet-phy-id0141.0dd4";
> > +		reg = <0x8>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +
> > +	sgmii_phy1: phy@a {
> > +		compatible = "ethernet-phy-id0141.0dd4";
> > +		reg = <0xa>;
> > +		device_type = "ethernet-phy";
> > +		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > +		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > +		reset-assert-us = <11000>;
> > +		reset-deassert-us = <70000>;
> > +	};
> > +};
> > --
> > 2.47.0
> > 

Thanks & Regards,
Wasim

[PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Wasim Nazir]

From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>

In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
does corrective action for each subsystem based on sensor violation
to comply safety standards. But as QCS9075 is non-safe SoC it
requires conventional thermal mitigation to control thermal for
different subsystems.

The cpu frequency throttling for different cpu tsens is enabled in
hardware as first defense for cpu thermal control. But QCS9075 SoC
has higher ambient specification. During high ambient condition, even
lowest frequency with multi cores can slowly build heat over the time
and it can lead to thermal run-away situations. This patch restrict
cpu cores during this scenario helps further thermal control and
avoids thermal critical violation.

Add cpu idle injection cooling bindings for cpu tsens thermal zones
as a mitigation for cpu subsystem prior to thermal shutdown.

Add cpu frequency cooling devices that will be used by userspace
thermal governor to mitigate skin thermal management.

Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
 arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |   1 +
 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
 4 files changed, 290 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi

diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
index ecaa383b6508..3ab6deeaacf1 100644
--- a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
+++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
@@ -9,6 +9,7 @@

 #include "sa8775p.dtsi"
 #include "sa8775p-pmics.dtsi"
+#include "qcs9075-thermal.dtsi"

 / {
 	model = "Qualcomm Technologies, Inc. Robotics RB8";
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
index d9a8956d3a76..5f2d9f416617 100644
--- a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
@@ -5,6 +5,7 @@
 /dts-v1/;

 #include "sa8775p-ride.dtsi"
+#include "qcs9075-thermal.dtsi"

 / {
 	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
index 3b524359a72d..10ce48e7ba2f 100644
--- a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
@@ -5,6 +5,7 @@
 /dts-v1/;

 #include "sa8775p-ride.dtsi"
+#include "qcs9075-thermal.dtsi"

 / {
 	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
new file mode 100644
index 000000000000..40544c8582c4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+&cpu0 {
+	#cooling-cells = <2>;
+};
+
+&cpu1 {
+	#cooling-cells = <2>;
+	cpu1_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu2 {
+	#cooling-cells = <2>;
+	cpu2_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu3 {
+	#cooling-cells = <2>;
+	cpu3_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu4 {
+	#cooling-cells = <2>;
+	cpu4_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu5 {
+	#cooling-cells = <2>;
+	cpu5_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu6 {
+	#cooling-cells = <2>;
+	cpu6_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+&cpu7 {
+	#cooling-cells = <2>;
+	cpu7_idle: thermal-idle {
+		#cooling-cells = <2>;
+		duration-us = <800000>;
+		exit-latency-us = <10000>;
+	};
+};
+
+/ {
+	thermal-zones {
+		cpu-0-1-0-thermal {
+			trips {
+				cpu_0_1_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_1_0_passive>;
+					cooling-device = <&cpu1_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-0-2-0-thermal {
+			trips {
+				cpu_0_2_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_2_0_passive>;
+					cooling-device = <&cpu2_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-0-3-0-thermal {
+			trips {
+				cpu_0_3_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_3_0_passive>;
+					cooling-device = <&cpu3_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-0-1-1-thermal {
+			trips {
+				cpu_0_1_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_1_1_passive>;
+					cooling-device = <&cpu1_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-0-2-1-thermal {
+			trips {
+				cpu_0_2_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_2_1_passive>;
+					cooling-device = <&cpu2_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-0-3-1-thermal {
+			trips {
+				cpu_0_3_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_0_3_1_passive>;
+					cooling-device = <&cpu3_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-0-0-thermal {
+			trips {
+				cpu_1_0_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_0_0_passive>;
+					cooling-device = <&cpu4_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-1-0-thermal {
+			trips {
+				cpu_1_1_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_1_0_passive>;
+					cooling-device = <&cpu5_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-2-0-thermal {
+			trips {
+				cpu_1_2_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_2_0_passive>;
+					cooling-device = <&cpu6_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-3-0-thermal {
+			trips {
+				cpu_1_3_0_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_3_0_passive>;
+					cooling-device = <&cpu7_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-0-1-thermal {
+			trips {
+				cpu_1_0_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_0_1_passive>;
+					cooling-device = <&cpu4_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-1-1-thermal {
+			trips {
+				cpu_1_1_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_1_1_passive>;
+					cooling-device = <&cpu5_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-2-1-thermal {
+			trips {
+				cpu_1_2_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_2_1_passive>;
+					cooling-device = <&cpu6_idle 100 100>;
+				};
+			};
+		};
+
+		cpu-1-3-1-thermal {
+			trips {
+				cpu_1_3_1_passive: trip-point1 {
+					temperature = <116000>;
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_1_3_1_passive>;
+					cooling-device = <&cpu7_idle 100 100>;
+				};
+			};
+		};
+	};
+};
--
2.47.0

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Aiqun(Maria) Yu]

On 12/29/2024 11:23 PM, Wasim Nazir wrote:
> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> 
> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
[...]
> Add cpu frequency cooling devices that will be used by userspace
> thermal governor to mitigate skin thermal management.
> 
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>

Also need to add SOB from the patch handler(Wasim).

Doc can reference [1].
snippets:
 - Signed-off-by: ``Patch handler <handler@mail>``

   SOBs after the author SOB are from people handling and transporting
   the patch, but were not involved in development. SOB chains should
   reflect the **real** route a patch took as it was propagated to us,
   with the first SOB entry signalling primary authorship of a single
   author.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/maintainer-tip.rst
[1]

> ---
>  arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
[...]
> 
>  #include "sa8775p-ride.dtsi"
> +#include "qcs9075-thermal.dtsi"

Thermal nodes are usually added by soc.dtsi chips like sa8775p.dtsi.
From the description, it seems that having thermal information is a
common feature for SOC qcs9075.

Would it be better to have below dts structure instead?:

1) Add a qcs9075.dtsi that includes sa8775p.dtsi and qcs9075-thermal.dtsi.
2) Have a qcs9075-ride.dtsi that includes sa8776p.dtsi and
qcs9075-thermal.dtsi.
3) Ensure all qcs9075 board dts include qcs9075-ride.dtsi

> 
>  / {
>  	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> new file mode 100644
> index 000000000000..40544c8582c4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&cpu0 {
> +	#cooling-cells = <2>;

Why is cpu0 treated specially when it doesn't include
cpu0_idle/thermal-idle nodes? Could you provide the information to the
commit message?

By the way, if there is no cpu0_idle, does that mean the #cooling-cell
is also not needed?

> +};
> +
> +&cpu1 {
[...]
> +
> +/ {
> +	thermal-zones {

The first /thermal-zones is located in sa8775p.dtsi. Should it have an
alias instead of referencing the whole node with the path? Using an
alias can help the reviewer check the previous node's information and
imply that it is an override rather than a newly added node.

> +		cpu-0-1-0-thermal {
> +			trips {
> +				cpu_0_1_0_passive: trip-point1 {

It seems like a common attribute for cpu1-cpu7. Can it be a common trips
node that can be referenced by different cpu-*-*-*-thermal nodes?


-- 
Thx and BRs,
Aiqun(Maria) Yu

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Konrad Dybcio]

On 29.12.2024 4:23 PM, Wasim Nazir wrote:
> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> 
> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> does corrective action for each subsystem based on sensor violation
> to comply safety standards. But as QCS9075 is non-safe SoC it
> requires conventional thermal mitigation to control thermal for
> different subsystems.
> 
> The cpu frequency throttling for different cpu tsens is enabled in
> hardware as first defense for cpu thermal control. But QCS9075 SoC
> has higher ambient specification. During high ambient condition, even
> lowest frequency with multi cores can slowly build heat over the time
> and it can lead to thermal run-away situations. This patch restrict
> cpu cores during this scenario helps further thermal control and
> avoids thermal critical violation.
> 
> Add cpu idle injection cooling bindings for cpu tsens thermal zones
> as a mitigation for cpu subsystem prior to thermal shutdown.
> 
> Add cpu frequency cooling devices that will be used by userspace
> thermal governor to mitigate skin thermal management.
> 
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> ---

Does this bring measurable benefits over just making the CPU a cooling
device and pointing the thermal zones to it (and not the idle subnode)?

Konrad

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Konrad,

On 12/30/2024 9:05 PM, Konrad Dybcio wrote:
> On 29.12.2024 4:23 PM, Wasim Nazir wrote:
>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>
>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>> does corrective action for each subsystem based on sensor violation
>> to comply safety standards. But as QCS9075 is non-safe SoC it
>> requires conventional thermal mitigation to control thermal for
>> different subsystems.
>>
>> The cpu frequency throttling for different cpu tsens is enabled in
>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>> has higher ambient specification. During high ambient condition, even
>> lowest frequency with multi cores can slowly build heat over the time
>> and it can lead to thermal run-away situations. This patch restrict
>> cpu cores during this scenario helps further thermal control and
>> avoids thermal critical violation.
>>
>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>
>> Add cpu frequency cooling devices that will be used by userspace
>> thermal governor to mitigate skin thermal management.
>>
>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>> ---
> Does this bring measurable benefits over just making the CPU a cooling
> device and pointing the thermal zones to it (and not the idle subnode)?
>
> Konrad
As noted in the commit, CPU frequency mitigation is handled by hardware 
as a first level mitigation. The software/scheduler will be updated via 
arch_update_hw_pressure API [1] for this mitigation. Adding the same CPU 
mitigation in thermal zones is redundant. We are adding idle injection 
with a 100% duty cycle as an additional mitigation step  at higher trip 
to further reduce CPU power consumption. This helps device thermal 
stability further, especially in high ambient conditions.

[1]. 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cpufreq/qcom-cpufreq-hw.c?h=next-20241220#n352

Best regards,

Manaf

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Konrad Dybcio]

On 31.12.2024 12:05 PM, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Konrad,
> 
> On 12/30/2024 9:05 PM, Konrad Dybcio wrote:
>> On 29.12.2024 4:23 PM, Wasim Nazir wrote:
>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>
>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>> does corrective action for each subsystem based on sensor violation
>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>> requires conventional thermal mitigation to control thermal for
>>> different subsystems.
>>>
>>> The cpu frequency throttling for different cpu tsens is enabled in
>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>> has higher ambient specification. During high ambient condition, even
>>> lowest frequency with multi cores can slowly build heat over the time
>>> and it can lead to thermal run-away situations. This patch restrict
>>> cpu cores during this scenario helps further thermal control and
>>> avoids thermal critical violation.
>>>
>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>
>>> Add cpu frequency cooling devices that will be used by userspace
>>> thermal governor to mitigate skin thermal management.
>>>
>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>> ---
>> Does this bring measurable benefits over just making the CPU a cooling
>> device and pointing the thermal zones to it (and not the idle subnode)?
>>
>> Konrad
> As noted in the commit, CPU frequency mitigation is handled by hardware as a first level mitigation. The software/scheduler will be updated via arch_update_hw_pressure API [1] for this mitigation. Adding the same CPU mitigation in thermal zones is redundant. We are adding idle injection with a 100% duty cycle as an additional mitigation step  at higher trip to further reduce CPU power consumption. This helps device thermal stability further, especially in high ambient conditions.

I understood this much from the commit message.

What I'm asking is, whether your solution actually works better than just
letting Linux software-throttle the CPUs, preferably backed by some
numbers.

I'm also unsure how this is supposed to reduce power consumption. If the
CPUs aren't busy, they should idle, and if they are not fully utilized, a
lower frequency would likely be scheduled.

Konrad


> 
> [1]. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cpufreq/qcom-cpufreq-hw.c?h=next-20241220#n352
> 
> Best regards,
> 
> Manaf
> 

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Konrad,

On 12/31/2024 9:51 PM, Konrad Dybcio wrote:
> On 31.12.2024 12:05 PM, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Konrad,
>>
>> On 12/30/2024 9:05 PM, Konrad Dybcio wrote:
>>> On 29.12.2024 4:23 PM, Wasim Nazir wrote:
>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>
>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>> does corrective action for each subsystem based on sensor violation
>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>> requires conventional thermal mitigation to control thermal for
>>>> different subsystems.
>>>>
>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>> has higher ambient specification. During high ambient condition, even
>>>> lowest frequency with multi cores can slowly build heat over the time
>>>> and it can lead to thermal run-away situations. This patch restrict
>>>> cpu cores during this scenario helps further thermal control and
>>>> avoids thermal critical violation.
>>>>
>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>
>>>> Add cpu frequency cooling devices that will be used by userspace
>>>> thermal governor to mitigate skin thermal management.
>>>>
>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>> ---
>>> Does this bring measurable benefits over just making the CPU a cooling
>>> device and pointing the thermal zones to it (and not the idle subnode)?
>>>
>>> Konrad
>> As noted in the commit, CPU frequency mitigation is handled by hardware as a first level mitigation. The software/scheduler will be updated via arch_update_hw_pressure API [1] for this mitigation. Adding the same CPU mitigation in thermal zones is redundant. We are adding idle injection with a 100% duty cycle as an additional mitigation step  at higher trip to further reduce CPU power consumption. This helps device thermal stability further, especially in high ambient conditions.
> I understood this much from the commit message.
>
> What I'm asking is, whether your solution actually works better than just
> letting Linux software-throttle the CPUs, preferably backed by some
> numbers.
I hope by ‘your solution’ you mean HW CPU frequency throttling. Yes, we 
benefit from the hardware approach compared to Linux software-based CPU 
throttling, both in terms of tighter thermal control and improved 
performance.
For the Dhrystone use case from one of our boards, we observe only a 
0.3°C overshoot compared to 2.5°C with software CPU throttling using the 
stepwise governor for same trip threshold.
>
> I'm also unsure how this is supposed to reduce power consumption. If the
> CPUs aren't busy, they should idle, and if they are not fully utilized, a
> lower frequency would likely be scheduled.

By using CPU idle injection, we force the CPU to enter idle mode with 
the lowest LPM modes during high temperature. This approach is similar 
to hot-plugging a core and will further reduce static power for that 
CPU, helping to manage temperature further.

[1]. https://docs.kernel.org/driver-api/thermal/cpu-idle-cooling.html

Best regards,

Manaf

>
> Konrad
>
>
>> [1]. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cpufreq/qcom-cpufreq-hw.c?h=next-20241220#n352
>>
>> Best regards,
>>
>> Manaf
>>

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> 
> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> does corrective action for each subsystem based on sensor violation
> to comply safety standards. But as QCS9075 is non-safe SoC it
> requires conventional thermal mitigation to control thermal for
> different subsystems.
> 
> The cpu frequency throttling for different cpu tsens is enabled in
> hardware as first defense for cpu thermal control. But QCS9075 SoC
> has higher ambient specification. During high ambient condition, even
> lowest frequency with multi cores can slowly build heat over the time
> and it can lead to thermal run-away situations. This patch restrict
> cpu cores during this scenario helps further thermal control and
> avoids thermal critical violation.
> 
> Add cpu idle injection cooling bindings for cpu tsens thermal zones
> as a mitigation for cpu subsystem prior to thermal shutdown.
> 
> Add cpu frequency cooling devices that will be used by userspace
> thermal governor to mitigate skin thermal management.

Does anything prevent us from having this config as a part of the basic
sa8775p.dtsi setup? If HW is present in the base version but it is not
accessible for whatever reason, please move it the base device config
and use status "disabled" or "reserved" to the respective board files.

> 
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
>  arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |   1 +
>  arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
>  4 files changed, 290 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> index ecaa383b6508..3ab6deeaacf1 100644
> --- a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> @@ -9,6 +9,7 @@
> 
>  #include "sa8775p.dtsi"
>  #include "sa8775p-pmics.dtsi"
> +#include "qcs9075-thermal.dtsi"
> 
>  / {
>  	model = "Qualcomm Technologies, Inc. Robotics RB8";
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> index d9a8956d3a76..5f2d9f416617 100644
> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -5,6 +5,7 @@
>  /dts-v1/;
> 
>  #include "sa8775p-ride.dtsi"
> +#include "qcs9075-thermal.dtsi"
> 
>  / {
>  	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> index 3b524359a72d..10ce48e7ba2f 100644
> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -5,6 +5,7 @@
>  /dts-v1/;
> 
>  #include "sa8775p-ride.dtsi"
> +#include "qcs9075-thermal.dtsi"
> 
>  / {
>  	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> new file mode 100644
> index 000000000000..40544c8582c4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&cpu0 {
> +	#cooling-cells = <2>;
> +};
> +
> +&cpu1 {
> +	#cooling-cells = <2>;
> +	cpu1_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu2 {
> +	#cooling-cells = <2>;
> +	cpu2_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu3 {
> +	#cooling-cells = <2>;
> +	cpu3_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu4 {
> +	#cooling-cells = <2>;
> +	cpu4_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu5 {
> +	#cooling-cells = <2>;
> +	cpu5_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu6 {
> +	#cooling-cells = <2>;
> +	cpu6_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +&cpu7 {
> +	#cooling-cells = <2>;
> +	cpu7_idle: thermal-idle {
> +		#cooling-cells = <2>;
> +		duration-us = <800000>;
> +		exit-latency-us = <10000>;
> +	};
> +};
> +
> +/ {
> +	thermal-zones {
> +		cpu-0-1-0-thermal {
> +			trips {
> +				cpu_0_1_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_1_0_passive>;
> +					cooling-device = <&cpu1_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-0-2-0-thermal {
> +			trips {
> +				cpu_0_2_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_2_0_passive>;
> +					cooling-device = <&cpu2_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-0-3-0-thermal {
> +			trips {
> +				cpu_0_3_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_3_0_passive>;
> +					cooling-device = <&cpu3_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-0-1-1-thermal {
> +			trips {
> +				cpu_0_1_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_1_1_passive>;
> +					cooling-device = <&cpu1_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-0-2-1-thermal {
> +			trips {
> +				cpu_0_2_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_2_1_passive>;
> +					cooling-device = <&cpu2_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-0-3-1-thermal {
> +			trips {
> +				cpu_0_3_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_0_3_1_passive>;
> +					cooling-device = <&cpu3_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-0-0-thermal {
> +			trips {
> +				cpu_1_0_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_0_0_passive>;
> +					cooling-device = <&cpu4_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-1-0-thermal {
> +			trips {
> +				cpu_1_1_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_1_0_passive>;
> +					cooling-device = <&cpu5_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-2-0-thermal {
> +			trips {
> +				cpu_1_2_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_2_0_passive>;
> +					cooling-device = <&cpu6_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-3-0-thermal {
> +			trips {
> +				cpu_1_3_0_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_3_0_passive>;
> +					cooling-device = <&cpu7_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-0-1-thermal {
> +			trips {
> +				cpu_1_0_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_0_1_passive>;
> +					cooling-device = <&cpu4_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-1-1-thermal {
> +			trips {
> +				cpu_1_1_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_1_1_passive>;
> +					cooling-device = <&cpu5_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-2-1-thermal {
> +			trips {
> +				cpu_1_2_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_2_1_passive>;
> +					cooling-device = <&cpu6_idle 100 100>;
> +				};
> +			};
> +		};
> +
> +		cpu-1-3-1-thermal {
> +			trips {
> +				cpu_1_3_1_passive: trip-point1 {
> +					temperature = <116000>;
> +				};
> +			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu_1_3_1_passive>;
> +					cooling-device = <&cpu7_idle 100 100>;
> +				};
> +			};
> +		};
> +	};
> +};
> --
> 2.47.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Dmitry,

On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>
>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>> does corrective action for each subsystem based on sensor violation
>> to comply safety standards. But as QCS9075 is non-safe SoC it
>> requires conventional thermal mitigation to control thermal for
>> different subsystems.
>>
>> The cpu frequency throttling for different cpu tsens is enabled in
>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>> has higher ambient specification. During high ambient condition, even
>> lowest frequency with multi cores can slowly build heat over the time
>> and it can lead to thermal run-away situations. This patch restrict
>> cpu cores during this scenario helps further thermal control and
>> avoids thermal critical violation.
>>
>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>
>> Add cpu frequency cooling devices that will be used by userspace
>> thermal governor to mitigate skin thermal management.
> Does anything prevent us from having this config as a part of the basic
> sa8775p.dtsi setup? If HW is present in the base version but it is not
> accessible for whatever reason, please move it the base device config
> and use status "disabled" or "reserved" to the respective board files.

Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and 
keep it disabled state. #cooling cells property for CPU, still wanted to 
keep it in board files as we don't want to enable any cooling device in 
base DT.

Best Regards,

Manaf

>
>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
>>   arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
>>   arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |   1 +
>>   arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
>>   4 files changed, 290 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>> index ecaa383b6508..3ab6deeaacf1 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>> @@ -9,6 +9,7 @@
>>
>>   #include "sa8775p.dtsi"
>>   #include "sa8775p-pmics.dtsi"
>> +#include "qcs9075-thermal.dtsi"
>>
>>   / {
>>   	model = "Qualcomm Technologies, Inc. Robotics RB8";
>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>> index d9a8956d3a76..5f2d9f416617 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>> @@ -5,6 +5,7 @@
>>   /dts-v1/;
>>
>>   #include "sa8775p-ride.dtsi"
>> +#include "qcs9075-thermal.dtsi"
>>
>>   / {
>>   	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>> index 3b524359a72d..10ce48e7ba2f 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>> @@ -5,6 +5,7 @@
>>   /dts-v1/;
>>
>>   #include "sa8775p-ride.dtsi"
>> +#include "qcs9075-thermal.dtsi"
>>
>>   / {
>>   	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>> new file mode 100644
>> index 000000000000..40544c8582c4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>> @@ -0,0 +1,287 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&cpu0 {
>> +	#cooling-cells = <2>;
>> +};
>> +
>> +&cpu1 {
>> +	#cooling-cells = <2>;
>> +	cpu1_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu2 {
>> +	#cooling-cells = <2>;
>> +	cpu2_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu3 {
>> +	#cooling-cells = <2>;
>> +	cpu3_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu4 {
>> +	#cooling-cells = <2>;
>> +	cpu4_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu5 {
>> +	#cooling-cells = <2>;
>> +	cpu5_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu6 {
>> +	#cooling-cells = <2>;
>> +	cpu6_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +&cpu7 {
>> +	#cooling-cells = <2>;
>> +	cpu7_idle: thermal-idle {
>> +		#cooling-cells = <2>;
>> +		duration-us = <800000>;
>> +		exit-latency-us = <10000>;
>> +	};
>> +};
>> +
>> +/ {
>> +	thermal-zones {
>> +		cpu-0-1-0-thermal {
>> +			trips {
>> +				cpu_0_1_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_1_0_passive>;
>> +					cooling-device = <&cpu1_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-0-2-0-thermal {
>> +			trips {
>> +				cpu_0_2_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_2_0_passive>;
>> +					cooling-device = <&cpu2_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-0-3-0-thermal {
>> +			trips {
>> +				cpu_0_3_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_3_0_passive>;
>> +					cooling-device = <&cpu3_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-0-1-1-thermal {
>> +			trips {
>> +				cpu_0_1_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_1_1_passive>;
>> +					cooling-device = <&cpu1_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-0-2-1-thermal {
>> +			trips {
>> +				cpu_0_2_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_2_1_passive>;
>> +					cooling-device = <&cpu2_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-0-3-1-thermal {
>> +			trips {
>> +				cpu_0_3_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_0_3_1_passive>;
>> +					cooling-device = <&cpu3_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-0-0-thermal {
>> +			trips {
>> +				cpu_1_0_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_0_0_passive>;
>> +					cooling-device = <&cpu4_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-1-0-thermal {
>> +			trips {
>> +				cpu_1_1_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_1_0_passive>;
>> +					cooling-device = <&cpu5_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-2-0-thermal {
>> +			trips {
>> +				cpu_1_2_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_2_0_passive>;
>> +					cooling-device = <&cpu6_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-3-0-thermal {
>> +			trips {
>> +				cpu_1_3_0_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_3_0_passive>;
>> +					cooling-device = <&cpu7_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-0-1-thermal {
>> +			trips {
>> +				cpu_1_0_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_0_1_passive>;
>> +					cooling-device = <&cpu4_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-1-1-thermal {
>> +			trips {
>> +				cpu_1_1_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_1_1_passive>;
>> +					cooling-device = <&cpu5_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-2-1-thermal {
>> +			trips {
>> +				cpu_1_2_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_2_1_passive>;
>> +					cooling-device = <&cpu6_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu-1-3-1-thermal {
>> +			trips {
>> +				cpu_1_3_1_passive: trip-point1 {
>> +					temperature = <116000>;
>> +				};
>> +			};
>> +
>> +			cooling-maps {
>> +				map0 {
>> +					trip = <&cpu_1_3_1_passive>;
>> +					cooling-device = <&cpu7_idle 100 100>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +};
>> --
>> 2.47.0
>>

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Dmitry,
> 
> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> > On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> > > From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> > > 
> > > In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> > > does corrective action for each subsystem based on sensor violation
> > > to comply safety standards. But as QCS9075 is non-safe SoC it
> > > requires conventional thermal mitigation to control thermal for
> > > different subsystems.
> > > 
> > > The cpu frequency throttling for different cpu tsens is enabled in
> > > hardware as first defense for cpu thermal control. But QCS9075 SoC
> > > has higher ambient specification. During high ambient condition, even
> > > lowest frequency with multi cores can slowly build heat over the time
> > > and it can lead to thermal run-away situations. This patch restrict
> > > cpu cores during this scenario helps further thermal control and
> > > avoids thermal critical violation.
> > > 
> > > Add cpu idle injection cooling bindings for cpu tsens thermal zones
> > > as a mitigation for cpu subsystem prior to thermal shutdown.
> > > 
> > > Add cpu frequency cooling devices that will be used by userspace
> > > thermal governor to mitigate skin thermal management.
> > Does anything prevent us from having this config as a part of the basic
> > sa8775p.dtsi setup? If HW is present in the base version but it is not
> > accessible for whatever reason, please move it the base device config
> > and use status "disabled" or "reserved" to the respective board files.
> 
> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
> it disabled state. #cooling cells property for CPU, still wanted to keep it
> in board files as we don't want to enable any cooling device in base DT.

"we don't want" is not a proper justification. So, no.

> 
> Best Regards,
> 
> Manaf
> 
> > 
> > > Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
> > >   arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
> > >   arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |   1 +
> > >   arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
> > >   4 files changed, 290 insertions(+)
> > >   create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> > > index ecaa383b6508..3ab6deeaacf1 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
> > > @@ -9,6 +9,7 @@
> > > 
> > >   #include "sa8775p.dtsi"
> > >   #include "sa8775p-pmics.dtsi"
> > > +#include "qcs9075-thermal.dtsi"
> > > 
> > >   / {
> > >   	model = "Qualcomm Technologies, Inc. Robotics RB8";
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > index d9a8956d3a76..5f2d9f416617 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > @@ -5,6 +5,7 @@
> > >   /dts-v1/;
> > > 
> > >   #include "sa8775p-ride.dtsi"
> > > +#include "qcs9075-thermal.dtsi"
> > > 
> > >   / {
> > >   	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > index 3b524359a72d..10ce48e7ba2f 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > @@ -5,6 +5,7 @@
> > >   /dts-v1/;
> > > 
> > >   #include "sa8775p-ride.dtsi"
> > > +#include "qcs9075-thermal.dtsi"
> > > 
> > >   / {
> > >   	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> > > new file mode 100644
> > > index 000000000000..40544c8582c4
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> > > @@ -0,0 +1,287 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/*
> > > + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> > > + */
> > > +
> > > +#include <dt-bindings/thermal/thermal.h>
> > > +
> > > +&cpu0 {
> > > +	#cooling-cells = <2>;
> > > +};
> > > +
> > > +&cpu1 {
> > > +	#cooling-cells = <2>;
> > > +	cpu1_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu2 {
> > > +	#cooling-cells = <2>;
> > > +	cpu2_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu3 {
> > > +	#cooling-cells = <2>;
> > > +	cpu3_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu4 {
> > > +	#cooling-cells = <2>;
> > > +	cpu4_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu5 {
> > > +	#cooling-cells = <2>;
> > > +	cpu5_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu6 {
> > > +	#cooling-cells = <2>;
> > > +	cpu6_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +&cpu7 {
> > > +	#cooling-cells = <2>;
> > > +	cpu7_idle: thermal-idle {
> > > +		#cooling-cells = <2>;
> > > +		duration-us = <800000>;
> > > +		exit-latency-us = <10000>;
> > > +	};
> > > +};
> > > +
> > > +/ {
> > > +	thermal-zones {
> > > +		cpu-0-1-0-thermal {
> > > +			trips {
> > > +				cpu_0_1_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_1_0_passive>;
> > > +					cooling-device = <&cpu1_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-0-2-0-thermal {
> > > +			trips {
> > > +				cpu_0_2_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_2_0_passive>;
> > > +					cooling-device = <&cpu2_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-0-3-0-thermal {
> > > +			trips {
> > > +				cpu_0_3_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_3_0_passive>;
> > > +					cooling-device = <&cpu3_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-0-1-1-thermal {
> > > +			trips {
> > > +				cpu_0_1_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_1_1_passive>;
> > > +					cooling-device = <&cpu1_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-0-2-1-thermal {
> > > +			trips {
> > > +				cpu_0_2_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_2_1_passive>;
> > > +					cooling-device = <&cpu2_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-0-3-1-thermal {
> > > +			trips {
> > > +				cpu_0_3_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_0_3_1_passive>;
> > > +					cooling-device = <&cpu3_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-0-0-thermal {
> > > +			trips {
> > > +				cpu_1_0_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_0_0_passive>;
> > > +					cooling-device = <&cpu4_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-1-0-thermal {
> > > +			trips {
> > > +				cpu_1_1_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_1_0_passive>;
> > > +					cooling-device = <&cpu5_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-2-0-thermal {
> > > +			trips {
> > > +				cpu_1_2_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_2_0_passive>;
> > > +					cooling-device = <&cpu6_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-3-0-thermal {
> > > +			trips {
> > > +				cpu_1_3_0_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_3_0_passive>;
> > > +					cooling-device = <&cpu7_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-0-1-thermal {
> > > +			trips {
> > > +				cpu_1_0_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_0_1_passive>;
> > > +					cooling-device = <&cpu4_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-1-1-thermal {
> > > +			trips {
> > > +				cpu_1_1_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_1_1_passive>;
> > > +					cooling-device = <&cpu5_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-2-1-thermal {
> > > +			trips {
> > > +				cpu_1_2_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_2_1_passive>;
> > > +					cooling-device = <&cpu6_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +
> > > +		cpu-1-3-1-thermal {
> > > +			trips {
> > > +				cpu_1_3_1_passive: trip-point1 {
> > > +					temperature = <116000>;
> > > +				};
> > > +			};
> > > +
> > > +			cooling-maps {
> > > +				map0 {
> > > +					trip = <&cpu_1_3_1_passive>;
> > > +					cooling-device = <&cpu7_idle 100 100>;
> > > +				};
> > > +			};
> > > +		};
> > > +	};
> > > +};
> > > --
> > > 2.47.0
> > > 

-- 
With best wishes
Dmitry

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Dmitry,


On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Dmitry,
>>
>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>
>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>> does corrective action for each subsystem based on sensor violation
>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>> requires conventional thermal mitigation to control thermal for
>>>> different subsystems.
>>>>
>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>> has higher ambient specification. During high ambient condition, even
>>>> lowest frequency with multi cores can slowly build heat over the time
>>>> and it can lead to thermal run-away situations. This patch restrict
>>>> cpu cores during this scenario helps further thermal control and
>>>> avoids thermal critical violation.
>>>>
>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>
>>>> Add cpu frequency cooling devices that will be used by userspace
>>>> thermal governor to mitigate skin thermal management.
>>> Does anything prevent us from having this config as a part of the basic
>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
>>> accessible for whatever reason, please move it the base device config
>>> and use status "disabled" or "reserved" to the respective board files.
>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
>> it disabled state. #cooling cells property for CPU, still wanted to keep it
>> in board files as we don't want to enable any cooling device in base DT.
> "we don't want" is not a proper justification. So, no.

As noted in the commit, thermal cooling mitigation is only necessary for 
non-safe SoCs. Adding this cooling cell property to the CPU node in the 
base DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, 
would violate the requirements for safe SoCs. Therefore, we will include 
it only in non-safe SoC boards.

Best Regards,

Manaf

>> Best Regards,
>>
>> Manaf
>>
>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      |   1 +
>>>>    arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |   1 +
>>>>    arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |   1 +
>>>>    arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
>>>>    4 files changed, 290 insertions(+)
>>>>    create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>>>> index ecaa383b6508..3ab6deeaacf1 100644
>>>> --- a/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>>>> @@ -9,6 +9,7 @@
>>>>
>>>>    #include "sa8775p.dtsi"
>>>>    #include "sa8775p-pmics.dtsi"
>>>> +#include "qcs9075-thermal.dtsi"
>>>>
>>>>    / {
>>>>    	model = "Qualcomm Technologies, Inc. Robotics RB8";
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>>>> index d9a8956d3a76..5f2d9f416617 100644
>>>> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>>>> @@ -5,6 +5,7 @@
>>>>    /dts-v1/;
>>>>
>>>>    #include "sa8775p-ride.dtsi"
>>>> +#include "qcs9075-thermal.dtsi"
>>>>
>>>>    / {
>>>>    	model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>>>> index 3b524359a72d..10ce48e7ba2f 100644
>>>> --- a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>>>> @@ -5,6 +5,7 @@
>>>>    /dts-v1/;
>>>>
>>>>    #include "sa8775p-ride.dtsi"
>>>> +#include "qcs9075-thermal.dtsi"
>>>>
>>>>    / {
>>>>    	model = "Qualcomm Technologies, Inc. QCS9075 Ride";
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>>>> new file mode 100644
>>>> index 000000000000..40544c8582c4
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
>>>> @@ -0,0 +1,287 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + */
>>>> +
>>>> +#include <dt-bindings/thermal/thermal.h>
>>>> +
>>>> +&cpu0 {
>>>> +	#cooling-cells = <2>;
>>>> +};
>>>> +
>>>> +&cpu1 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu1_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu2 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu2_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu3 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu3_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu4 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu4_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu5 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu5_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu6 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu6_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&cpu7 {
>>>> +	#cooling-cells = <2>;
>>>> +	cpu7_idle: thermal-idle {
>>>> +		#cooling-cells = <2>;
>>>> +		duration-us = <800000>;
>>>> +		exit-latency-us = <10000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +/ {
>>>> +	thermal-zones {
>>>> +		cpu-0-1-0-thermal {
>>>> +			trips {
>>>> +				cpu_0_1_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_1_0_passive>;
>>>> +					cooling-device = <&cpu1_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-0-2-0-thermal {
>>>> +			trips {
>>>> +				cpu_0_2_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_2_0_passive>;
>>>> +					cooling-device = <&cpu2_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-0-3-0-thermal {
>>>> +			trips {
>>>> +				cpu_0_3_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_3_0_passive>;
>>>> +					cooling-device = <&cpu3_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-0-1-1-thermal {
>>>> +			trips {
>>>> +				cpu_0_1_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_1_1_passive>;
>>>> +					cooling-device = <&cpu1_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-0-2-1-thermal {
>>>> +			trips {
>>>> +				cpu_0_2_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_2_1_passive>;
>>>> +					cooling-device = <&cpu2_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-0-3-1-thermal {
>>>> +			trips {
>>>> +				cpu_0_3_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_0_3_1_passive>;
>>>> +					cooling-device = <&cpu3_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-0-0-thermal {
>>>> +			trips {
>>>> +				cpu_1_0_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_0_0_passive>;
>>>> +					cooling-device = <&cpu4_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-1-0-thermal {
>>>> +			trips {
>>>> +				cpu_1_1_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_1_0_passive>;
>>>> +					cooling-device = <&cpu5_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-2-0-thermal {
>>>> +			trips {
>>>> +				cpu_1_2_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_2_0_passive>;
>>>> +					cooling-device = <&cpu6_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-3-0-thermal {
>>>> +			trips {
>>>> +				cpu_1_3_0_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_3_0_passive>;
>>>> +					cooling-device = <&cpu7_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-0-1-thermal {
>>>> +			trips {
>>>> +				cpu_1_0_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_0_1_passive>;
>>>> +					cooling-device = <&cpu4_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-1-1-thermal {
>>>> +			trips {
>>>> +				cpu_1_1_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_1_1_passive>;
>>>> +					cooling-device = <&cpu5_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-2-1-thermal {
>>>> +			trips {
>>>> +				cpu_1_2_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_2_1_passive>;
>>>> +					cooling-device = <&cpu6_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +
>>>> +		cpu-1-3-1-thermal {
>>>> +			trips {
>>>> +				cpu_1_3_1_passive: trip-point1 {
>>>> +					temperature = <116000>;
>>>> +				};
>>>> +			};
>>>> +
>>>> +			cooling-maps {
>>>> +				map0 {
>>>> +					trip = <&cpu_1_3_1_passive>;
>>>> +					cooling-device = <&cpu7_idle 100 100>;
>>>> +				};
>>>> +			};
>>>> +		};
>>>> +	};
>>>> +};
>>>> --
>>>> 2.47.0
>>>>

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Dmitry,
> 
> 
> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > Hi Dmitry,
> > > 
> > > On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> > > > On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> > > > > From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> > > > > 
> > > > > In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> > > > > does corrective action for each subsystem based on sensor violation
> > > > > to comply safety standards. But as QCS9075 is non-safe SoC it
> > > > > requires conventional thermal mitigation to control thermal for
> > > > > different subsystems.
> > > > > 
> > > > > The cpu frequency throttling for different cpu tsens is enabled in
> > > > > hardware as first defense for cpu thermal control. But QCS9075 SoC
> > > > > has higher ambient specification. During high ambient condition, even
> > > > > lowest frequency with multi cores can slowly build heat over the time
> > > > > and it can lead to thermal run-away situations. This patch restrict
> > > > > cpu cores during this scenario helps further thermal control and
> > > > > avoids thermal critical violation.
> > > > > 
> > > > > Add cpu idle injection cooling bindings for cpu tsens thermal zones
> > > > > as a mitigation for cpu subsystem prior to thermal shutdown.
> > > > > 
> > > > > Add cpu frequency cooling devices that will be used by userspace
> > > > > thermal governor to mitigate skin thermal management.
> > > > Does anything prevent us from having this config as a part of the basic
> > > > sa8775p.dtsi setup? If HW is present in the base version but it is not
> > > > accessible for whatever reason, please move it the base device config
> > > > and use status "disabled" or "reserved" to the respective board files.
> > > Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
> > > it disabled state. #cooling cells property for CPU, still wanted to keep it
> > > in board files as we don't want to enable any cooling device in base DT.
> > "we don't want" is not a proper justification. So, no.
> 
> As noted in the commit, thermal cooling mitigation is only necessary for
> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
> violate the requirements for safe SoCs. Therefore, we will include it only
> in non-safe SoC boards.

"is only necessary" is fine. It means that it is an optional part which
is going to be unused / ignored / duplicate functionality on the "safe"
SoCs. What kind of requirement is going to be violated in this way?


-- 
With best wishes
Dmitry

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Dmitry,


On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
> On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Dmitry,
>>
>>
>> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
>>> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
>>>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>>>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>>>
>>>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>>>> does corrective action for each subsystem based on sensor violation
>>>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>>>> requires conventional thermal mitigation to control thermal for
>>>>>> different subsystems.
>>>>>>
>>>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>>>> has higher ambient specification. During high ambient condition, even
>>>>>> lowest frequency with multi cores can slowly build heat over the time
>>>>>> and it can lead to thermal run-away situations. This patch restrict
>>>>>> cpu cores during this scenario helps further thermal control and
>>>>>> avoids thermal critical violation.
>>>>>>
>>>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>>>
>>>>>> Add cpu frequency cooling devices that will be used by userspace
>>>>>> thermal governor to mitigate skin thermal management.
>>>>> Does anything prevent us from having this config as a part of the basic
>>>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
>>>>> accessible for whatever reason, please move it the base device config
>>>>> and use status "disabled" or "reserved" to the respective board files.
>>>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
>>>> it disabled state. #cooling cells property for CPU, still wanted to keep it
>>>> in board files as we don't want to enable any cooling device in base DT.
>>> "we don't want" is not a proper justification. So, no.
>> As noted in the commit, thermal cooling mitigation is only necessary for
>> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
>> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
>> violate the requirements for safe SoCs. Therefore, we will include it only
>> in non-safe SoC boards.
> "is only necessary" is fine. It means that it is an optional part which
> is going to be unused / ignored / duplicate functionality on the "safe"
> SoCs. What kind of requirement is going to be violated in this way?

 From the perspective of a safe SoC, any software mitigation that 
compromises the safety subsystem’s compliance should not be allowed. 
Enabling the cooling device also opens up the sysfs interface for 
userspace, which we may not fully control. Userspace apps or partner 
apps might inadvertently use it. Therefore, we believe it is better not 
to expose such an interface, as it is not required for that SoC and 
helps to avoid opening up an interface that could potentially lead to a 
safety failure.

Best Regards,

Manaf

>

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Konrad Dybcio]

On 8.01.2025 5:08 PM, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Dmitry,
> 
> 
> On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
>> On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>> Hi Dmitry,
>>>
>>>
>>> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
>>>> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
>>>>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>>>>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>>>>
>>>>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>>>>> does corrective action for each subsystem based on sensor violation
>>>>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>>>>> requires conventional thermal mitigation to control thermal for
>>>>>>> different subsystems.
>>>>>>>
>>>>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>>>>> has higher ambient specification. During high ambient condition, even
>>>>>>> lowest frequency with multi cores can slowly build heat over the time
>>>>>>> and it can lead to thermal run-away situations. This patch restrict
>>>>>>> cpu cores during this scenario helps further thermal control and
>>>>>>> avoids thermal critical violation.
>>>>>>>
>>>>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>>>>
>>>>>>> Add cpu frequency cooling devices that will be used by userspace
>>>>>>> thermal governor to mitigate skin thermal management.
>>>>>> Does anything prevent us from having this config as a part of the basic
>>>>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
>>>>>> accessible for whatever reason, please move it the base device config
>>>>>> and use status "disabled" or "reserved" to the respective board files.
>>>>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
>>>>> it disabled state. #cooling cells property for CPU, still wanted to keep it
>>>>> in board files as we don't want to enable any cooling device in base DT.
>>>> "we don't want" is not a proper justification. So, no.
>>> As noted in the commit, thermal cooling mitigation is only necessary for
>>> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
>>> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
>>> violate the requirements for safe SoCs. Therefore, we will include it only
>>> in non-safe SoC boards.
>> "is only necessary" is fine. It means that it is an optional part which
>> is going to be unused / ignored / duplicate functionality on the "safe"
>> SoCs. What kind of requirement is going to be violated in this way?
> 
> From the perspective of a safe SoC, any software mitigation that compromises the safety subsystem’s compliance should not be allowed. Enabling the cooling device also opens up the sysfs interface for userspace, which we may not fully control. Userspace apps or partner apps might inadvertently use it. Therefore, we believe it is better not to expose such an interface, as it is not required for that SoC and helps to avoid opening up an interface that could potentially lead to a safety failure.

So, to recalibrate, would this be accurate?:

* "safe" SoCs are the ones with a SAIL/Safety Island block which
  performs thermal throttling without OS intervention and does so
  on all SAIL-equipped platforms

* SoCs with a SAIL are intended to be used in e.g. cars and if we
  want to keep mainline viable on those, we must comply with some
  regulations, which prevent e.g. software thermal throttling

* idle injection provides measurable improvements over software-
  based frequency throttling on platforms with SAIL

Konrad

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Wed, Jan 08, 2025 at 09:38:19PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Dmitry,
> 
> 
> On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
> > On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > Hi Dmitry,
> > > 
> > > 
> > > On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
> > > > On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > > > Hi Dmitry,
> > > > > 
> > > > > On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> > > > > > On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> > > > > > > From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> > > > > > > 
> > > > > > > In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> > > > > > > does corrective action for each subsystem based on sensor violation
> > > > > > > to comply safety standards. But as QCS9075 is non-safe SoC it
> > > > > > > requires conventional thermal mitigation to control thermal for
> > > > > > > different subsystems.
> > > > > > > 
> > > > > > > The cpu frequency throttling for different cpu tsens is enabled in
> > > > > > > hardware as first defense for cpu thermal control. But QCS9075 SoC
> > > > > > > has higher ambient specification. During high ambient condition, even
> > > > > > > lowest frequency with multi cores can slowly build heat over the time
> > > > > > > and it can lead to thermal run-away situations. This patch restrict
> > > > > > > cpu cores during this scenario helps further thermal control and
> > > > > > > avoids thermal critical violation.
> > > > > > > 
> > > > > > > Add cpu idle injection cooling bindings for cpu tsens thermal zones
> > > > > > > as a mitigation for cpu subsystem prior to thermal shutdown.
> > > > > > > 
> > > > > > > Add cpu frequency cooling devices that will be used by userspace
> > > > > > > thermal governor to mitigate skin thermal management.
> > > > > > Does anything prevent us from having this config as a part of the basic
> > > > > > sa8775p.dtsi setup? If HW is present in the base version but it is not
> > > > > > accessible for whatever reason, please move it the base device config
> > > > > > and use status "disabled" or "reserved" to the respective board files.
> > > > > Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
> > > > > it disabled state. #cooling cells property for CPU, still wanted to keep it
> > > > > in board files as we don't want to enable any cooling device in base DT.
> > > > "we don't want" is not a proper justification. So, no.
> > > As noted in the commit, thermal cooling mitigation is only necessary for
> > > non-safe SoCs. Adding this cooling cell property to the CPU node in the base
> > > DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
> > > violate the requirements for safe SoCs. Therefore, we will include it only
> > > in non-safe SoC boards.
> > "is only necessary" is fine. It means that it is an optional part which
> > is going to be unused / ignored / duplicate functionality on the "safe"
> > SoCs. What kind of requirement is going to be violated in this way?
> 
> From the perspective of a safe SoC, any software mitigation that compromises
> the safety subsystem’s compliance should not be allowed. Enabling the
> cooling device also opens up the sysfs interface for userspace, which we may
> not fully control.

THere are a lot of interfaces exported to the userspace.

> Userspace apps or partner apps might inadvertently use
> it. Therefore, we believe it is better not to expose such an interface, as
> it is not required for that SoC and helps to avoid opening up an interface
> that could potentially lead to a safety failure.

How can thermal mitigation interface lead to safety failure? Userspace
can possibly lower trip points, but it can not override existing
firmware-based mitigation.
And if there is a known problem with the interface, it should be fixed
instead.

> 
> Best Regards,
> 
> Manaf
> 
> > 

-- 
With best wishes
Dmitry

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Konrad Dybcio]

On 10.01.2025 12:54 AM, Dmitry Baryshkov wrote:
> On Wed, Jan 08, 2025 at 09:38:19PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>
>> Hi Dmitry,
>>
>>
>> On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
>>> On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>> Hi Dmitry,
>>>>
>>>>
>>>> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
>>>>> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
>>>>>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>>>>>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>>>>>
>>>>>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>>>>>> does corrective action for each subsystem based on sensor violation
>>>>>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>>>>>> requires conventional thermal mitigation to control thermal for
>>>>>>>> different subsystems.
>>>>>>>>
>>>>>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>>>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>>>>>> has higher ambient specification. During high ambient condition, even
>>>>>>>> lowest frequency with multi cores can slowly build heat over the time
>>>>>>>> and it can lead to thermal run-away situations. This patch restrict
>>>>>>>> cpu cores during this scenario helps further thermal control and
>>>>>>>> avoids thermal critical violation.
>>>>>>>>
>>>>>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>>>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>>>>>
>>>>>>>> Add cpu frequency cooling devices that will be used by userspace
>>>>>>>> thermal governor to mitigate skin thermal management.
>>>>>>> Does anything prevent us from having this config as a part of the basic
>>>>>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
>>>>>>> accessible for whatever reason, please move it the base device config
>>>>>>> and use status "disabled" or "reserved" to the respective board files.
>>>>>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
>>>>>> it disabled state. #cooling cells property for CPU, still wanted to keep it
>>>>>> in board files as we don't want to enable any cooling device in base DT.
>>>>> "we don't want" is not a proper justification. So, no.
>>>> As noted in the commit, thermal cooling mitigation is only necessary for
>>>> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
>>>> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
>>>> violate the requirements for safe SoCs. Therefore, we will include it only
>>>> in non-safe SoC boards.
>>> "is only necessary" is fine. It means that it is an optional part which
>>> is going to be unused / ignored / duplicate functionality on the "safe"
>>> SoCs. What kind of requirement is going to be violated in this way?
>>
>> From the perspective of a safe SoC, any software mitigation that compromises
>> the safety subsystem’s compliance should not be allowed. Enabling the
>> cooling device also opens up the sysfs interface for userspace, which we may
>> not fully control.
> 
> THere are a lot of interfaces exported to the userspace.
> 
>> Userspace apps or partner apps might inadvertently use
>> it. Therefore, we believe it is better not to expose such an interface, as
>> it is not required for that SoC and helps to avoid opening up an interface
>> that could potentially lead to a safety failure.
> 
> How can thermal mitigation interface lead to safety failure? Userspace
> can possibly lower trip points, but it can not override existing
> firmware-based mitigation.
> And if there is a known problem with the interface, it should be fixed
> instead.

I think the intended case to avoid is where a malicious actor would set
the trips too low, resulting in throttling down the CPU to FMIN / Linux
throttling CPUs to try and escape what it believes to be possible thermal
runaway / a system reboot. Not something desired in a car.

Konrad

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Fri, Jan 10, 2025 at 01:31:00PM +0100, Konrad Dybcio wrote:
> On 10.01.2025 12:54 AM, Dmitry Baryshkov wrote:
> > On Wed, Jan 08, 2025 at 09:38:19PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> >>
> >> Hi Dmitry,
> >>
> >>
> >> On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
> >>> On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> >>>> Hi Dmitry,
> >>>>
> >>>>
> >>>> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
> >>>>> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> >>>>>> Hi Dmitry,
> >>>>>>
> >>>>>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> >>>>>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> >>>>>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> >>>>>>>>
> >>>>>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> >>>>>>>> does corrective action for each subsystem based on sensor violation
> >>>>>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
> >>>>>>>> requires conventional thermal mitigation to control thermal for
> >>>>>>>> different subsystems.
> >>>>>>>>
> >>>>>>>> The cpu frequency throttling for different cpu tsens is enabled in
> >>>>>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
> >>>>>>>> has higher ambient specification. During high ambient condition, even
> >>>>>>>> lowest frequency with multi cores can slowly build heat over the time
> >>>>>>>> and it can lead to thermal run-away situations. This patch restrict
> >>>>>>>> cpu cores during this scenario helps further thermal control and
> >>>>>>>> avoids thermal critical violation.
> >>>>>>>>
> >>>>>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
> >>>>>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
> >>>>>>>>
> >>>>>>>> Add cpu frequency cooling devices that will be used by userspace
> >>>>>>>> thermal governor to mitigate skin thermal management.
> >>>>>>> Does anything prevent us from having this config as a part of the basic
> >>>>>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
> >>>>>>> accessible for whatever reason, please move it the base device config
> >>>>>>> and use status "disabled" or "reserved" to the respective board files.
> >>>>>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
> >>>>>> it disabled state. #cooling cells property for CPU, still wanted to keep it
> >>>>>> in board files as we don't want to enable any cooling device in base DT.
> >>>>> "we don't want" is not a proper justification. So, no.
> >>>> As noted in the commit, thermal cooling mitigation is only necessary for
> >>>> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
> >>>> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
> >>>> violate the requirements for safe SoCs. Therefore, we will include it only
> >>>> in non-safe SoC boards.
> >>> "is only necessary" is fine. It means that it is an optional part which
> >>> is going to be unused / ignored / duplicate functionality on the "safe"
> >>> SoCs. What kind of requirement is going to be violated in this way?
> >>
> >> From the perspective of a safe SoC, any software mitigation that compromises
> >> the safety subsystem’s compliance should not be allowed. Enabling the
> >> cooling device also opens up the sysfs interface for userspace, which we may
> >> not fully control.
> > 
> > THere are a lot of interfaces exported to the userspace.
> > 
> >> Userspace apps or partner apps might inadvertently use
> >> it. Therefore, we believe it is better not to expose such an interface, as
> >> it is not required for that SoC and helps to avoid opening up an interface
> >> that could potentially lead to a safety failure.
> > 
> > How can thermal mitigation interface lead to safety failure? Userspace
> > can possibly lower trip points, but it can not override existing
> > firmware-based mitigation.
> > And if there is a known problem with the interface, it should be fixed
> > instead.
> 
> I think the intended case to avoid is where a malicious actor would set
> the trips too low, resulting in throttling down the CPU to FMIN / Linux
> throttling CPUs to try and escape what it believes to be possible thermal
> runaway / a system reboot. Not something desired in a car.

Being able to set trip points via sysfs means that the system is already
compromised. At this point it can do whatever the actor wants - e.g.
display malicious HUD or just a gren bar or black screen, scream into
dynamic, etc. That doesn't sound like the temperature trip points being
the only or the major problem of a car.

Anyway, if that's really the only problem, please use the framework to
make the temperature and hysteresis of the trip point R/O for sa8775p /
qcs9100. Other attributes might need to be made R/O too. It well might
be that I'm missing one of the automotive peculiarties here. In such a
case the commit message should be more explicit that it's AGL or some
other requirement and provide a link.

-- 
With best wishes
Dmitry

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Manaf Meethalavalappu Pallikunhi]

Hi Dmitry,

Sorry, I was busy with some other priority tasks.

On 1/10/2025 5:24 AM, Dmitry Baryshkov wrote:
> On Wed, Jan 08, 2025 at 09:38:19PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Dmitry,
>>
>>
>> On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
>>> On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>> Hi Dmitry,
>>>>
>>>>
>>>> On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
>>>>> On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
>>>>>>> On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
>>>>>>>> From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
>>>>>>>>
>>>>>>>> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
>>>>>>>> does corrective action for each subsystem based on sensor violation
>>>>>>>> to comply safety standards. But as QCS9075 is non-safe SoC it
>>>>>>>> requires conventional thermal mitigation to control thermal for
>>>>>>>> different subsystems.
>>>>>>>>
>>>>>>>> The cpu frequency throttling for different cpu tsens is enabled in
>>>>>>>> hardware as first defense for cpu thermal control. But QCS9075 SoC
>>>>>>>> has higher ambient specification. During high ambient condition, even
>>>>>>>> lowest frequency with multi cores can slowly build heat over the time
>>>>>>>> and it can lead to thermal run-away situations. This patch restrict
>>>>>>>> cpu cores during this scenario helps further thermal control and
>>>>>>>> avoids thermal critical violation.
>>>>>>>>
>>>>>>>> Add cpu idle injection cooling bindings for cpu tsens thermal zones
>>>>>>>> as a mitigation for cpu subsystem prior to thermal shutdown.
>>>>>>>>
>>>>>>>> Add cpu frequency cooling devices that will be used by userspace
>>>>>>>> thermal governor to mitigate skin thermal management.
>>>>>>> Does anything prevent us from having this config as a part of the basic
>>>>>>> sa8775p.dtsi setup? If HW is present in the base version but it is not
>>>>>>> accessible for whatever reason, please move it the base device config
>>>>>>> and use status "disabled" or "reserved" to the respective board files.
>>>>>> Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
>>>>>> it disabled state. #cooling cells property for CPU, still wanted to keep it
>>>>>> in board files as we don't want to enable any cooling device in base DT.
>>>>> "we don't want" is not a proper justification. So, no.
>>>> As noted in the commit, thermal cooling mitigation is only necessary for
>>>> non-safe SoCs. Adding this cooling cell property to the CPU node in the base
>>>> DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
>>>> violate the requirements for safe SoCs. Therefore, we will include it only
>>>> in non-safe SoC boards.
>>> "is only necessary" is fine. It means that it is an optional part which
>>> is going to be unused / ignored / duplicate functionality on the "safe"
>>> SoCs. What kind of requirement is going to be violated in this way?
>>  From the perspective of a safe SoC, any software mitigation that compromises
>> the safety subsystem’s compliance should not be allowed. Enabling the
>> cooling device also opens up the sysfs interface for userspace, which we may
>> not fully control.
> THere are a lot of interfaces exported to the userspace.
>
>> Userspace apps or partner apps might inadvertently use
>> it. Therefore, we believe it is better not to expose such an interface, as
>> it is not required for that SoC and helps to avoid opening up an interface
>> that could potentially lead to a safety failure.
> How can thermal mitigation interface lead to safety failure? Userspace
> can possibly lower trip points, but it can not override existing
> firmware-based mitigation.
Both firmware and software passive mitigations (CPU/GPU) are not 
permitted for Safe SoC. As mentioned in the commit, it is the 
responsibility of the safety subsystem to take corrective action for 
high temperatures. One of the safety requirements (not a functional 
requirement) for Safe SoC is to avoid scaling of CPUs and bus DCVS, as 
this could impact safety-critical workloads. Therefore, Safe SoC will 
operate at maximum frequency with the performance governor. Enabling a 
cooling device for the CPU would expose the cooling device sysfs 
interface, allowing userspace to request different cooling states via 
the cooling device cur_state sysfs, which could potentially lower the 
frequency and violate the safety requirement.
> And if there is a known problem with the interface, it should be fixed
> instead.

There is no interface issue, as it is not required and can be disabled 
for Safe SoC. This approach has already been used for commercializing 
the SA8775P, and we do not want to disrupt it now. Therefore, we believe 
it is better not to add cpu cooling cell property (CPU cooling device) 
in sa8775p base dtsi.

Best Regards,

Manaf

>
>> Best Regards,
>>
>> Manaf
>>

Re: [PATCH v5 6/6] arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms

[Dmitry Baryshkov]

On Wed, Jan 15, 2025 at 12:46:50AM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> 
> Hi Dmitry,
> 
> Sorry, I was busy with some other priority tasks.
> 
> On 1/10/2025 5:24 AM, Dmitry Baryshkov wrote:
> > On Wed, Jan 08, 2025 at 09:38:19PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > Hi Dmitry,
> > > 
> > > 
> > > On 1/8/2025 6:16 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Jan 08, 2025 at 05:57:06PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > > > Hi Dmitry,
> > > > > 
> > > > > 
> > > > > On 1/3/2025 11:21 AM, Dmitry Baryshkov wrote:
> > > > > > On Tue, Dec 31, 2024 at 05:31:41PM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> > > > > > > Hi Dmitry,
> > > > > > > 
> > > > > > > On 12/30/2024 9:10 PM, Dmitry Baryshkov wrote:
> > > > > > > > On Sun, Dec 29, 2024 at 08:53:32PM +0530, Wasim Nazir wrote:
> > > > > > > > > From: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
> > > > > > > > > 
> > > > > > > > > In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> > > > > > > > > does corrective action for each subsystem based on sensor violation
> > > > > > > > > to comply safety standards. But as QCS9075 is non-safe SoC it
> > > > > > > > > requires conventional thermal mitigation to control thermal for
> > > > > > > > > different subsystems.
> > > > > > > > > 
> > > > > > > > > The cpu frequency throttling for different cpu tsens is enabled in
> > > > > > > > > hardware as first defense for cpu thermal control. But QCS9075 SoC
> > > > > > > > > has higher ambient specification. During high ambient condition, even
> > > > > > > > > lowest frequency with multi cores can slowly build heat over the time
> > > > > > > > > and it can lead to thermal run-away situations. This patch restrict
> > > > > > > > > cpu cores during this scenario helps further thermal control and
> > > > > > > > > avoids thermal critical violation.
> > > > > > > > > 
> > > > > > > > > Add cpu idle injection cooling bindings for cpu tsens thermal zones
> > > > > > > > > as a mitigation for cpu subsystem prior to thermal shutdown.
> > > > > > > > > 
> > > > > > > > > Add cpu frequency cooling devices that will be used by userspace
> > > > > > > > > thermal governor to mitigate skin thermal management.
> > > > > > > > Does anything prevent us from having this config as a part of the basic
> > > > > > > > sa8775p.dtsi setup? If HW is present in the base version but it is not
> > > > > > > > accessible for whatever reason, please move it the base device config
> > > > > > > > and use status "disabled" or "reserved" to the respective board files.
> > > > > > > Sure,  I will move idle injection node for each cpu to sa8775p.dtsi and keep
> > > > > > > it disabled state. #cooling cells property for CPU, still wanted to keep it
> > > > > > > in board files as we don't want to enable any cooling device in base DT.
> > > > > > "we don't want" is not a proper justification. So, no.
> > > > > As noted in the commit, thermal cooling mitigation is only necessary for
> > > > > non-safe SoCs. Adding this cooling cell property to the CPU node in the base
> > > > > DT (sa8775p.dtsi), which is shared by both safe and non-safe SoCs, would
> > > > > violate the requirements for safe SoCs. Therefore, we will include it only
> > > > > in non-safe SoC boards.
> > > > "is only necessary" is fine. It means that it is an optional part which
> > > > is going to be unused / ignored / duplicate functionality on the "safe"
> > > > SoCs. What kind of requirement is going to be violated in this way?
> > >  From the perspective of a safe SoC, any software mitigation that compromises
> > > the safety subsystem’s compliance should not be allowed. Enabling the
> > > cooling device also opens up the sysfs interface for userspace, which we may
> > > not fully control.
> > THere are a lot of interfaces exported to the userspace.
> > 
> > > Userspace apps or partner apps might inadvertently use
> > > it. Therefore, we believe it is better not to expose such an interface, as
> > > it is not required for that SoC and helps to avoid opening up an interface
> > > that could potentially lead to a safety failure.
> > How can thermal mitigation interface lead to safety failure? Userspace
> > can possibly lower trip points, but it can not override existing
> > firmware-based mitigation.
> Both firmware and software passive mitigations (CPU/GPU) are not permitted
> for Safe SoC.

Not permitted by whom?

> As mentioned in the commit, it is the responsibility of the
> safety subsystem to take corrective action for high temperatures. One of the
> safety requirements (not a functional requirement) for Safe SoC is to avoid
> scaling of CPUs and bus DCVS, as this could impact safety-critical
> workloads. Therefore, Safe SoC will operate at maximum frequency with the
> performance governor. Enabling a cooling device for the CPU would expose the
> cooling device sysfs interface, allowing userspace to request different
> cooling states via the cooling device cur_state sysfs, which could
> potentially lower the frequency and violate the safety requirement.

So, you disable thermal mitigation controls, but your description allows
userspace to change the CPUfreq governor through sysfs. Isn't that also
unsafe?

> > And if there is a known problem with the interface, it should be fixed
> > instead.
> 
> There is no interface issue, as it is not required and can be disabled for
> Safe SoC. This approach has already been used for commercializing the
> SA8775P, and we do not want to disrupt it now. Therefore, we believe it is
> better not to add cpu cooling cell property (CPU cooling device) in sa8775p
> base dtsi.

Okay, assuming  SA8775P may not have any thermal-related properties,
what is the issue with having them for the IoT-related QCS9100 device?

So, you have an alternative proposal: rename sa8775p.dtsi to
qcs9100.dtsi, defining a full set of thermal properties there and add
sa8775p.dtsi which includes qcs9100.dtsi and just removes thermal and
cpufreq nodes. Doing it in any other way, especially by including a
random SoC-related include defeats the logic of the DTSI files.

> 
> Best Regards,
> 
> Manaf
> 
> > 
> > > Best Regards,
> > > 
> > > Manaf
> > > 

-- 
With best wishes
Dmitry

Re: [PATCH v5 0/6] arm64: qcom: Add support for QCS9075 boards

[Rob Herring (Arm)]

On Sun, 29 Dec 2024 20:53:26 +0530, Wasim Nazir wrote:
> This series:
> 
> Add support for Qualcomm's rb8, ride/ride-r3 boards using QCS9075 SoC.
> 
> QCS9075 is compatible IoT-industrial grade variant of SA8775p SoC.
> Unlike QCS9100, it doesn't have safety monitoring feature of
> Safety-Island(SAIL) subsystem, which affects thermal management.
> 
> In QCS9100 SoC, the safety subsystem monitors all thermal sensors and
> does corrective action for each subsystem based on sensor violation
> to comply safety standards. But as QCS9075 is non-safe SoC it requires
> conventional thermal mitigation for thermal management.
> 
> Difference between Ride & ride-r3 boards is ethernet phy,
> ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> 
> This series depends on [1] for thermal functionality to work.
> 
> [1]: https://lore.kernel.org/all/20241112-sa8775p_cpuidle-v1-1-66ff3ba72464@quicinc.com/
> 
> ---
> Changelog:
> 
> v5:
>   - Remove defconfig patch as the config is product specific.
>   - v4: https://lore.kernel.org/all/20241217064856.2772305-1-quic_wasimn@quicinc.com/
> 
> v4:
>   - Replace dts to dtsi in Ride/Ride-r3 platform files.
>   - Add thermal patch to differentiate between 9100 vs 9075.
>   - Add proper abbreviation and update commit for 9100 vs 9075.
>   - v3: https://lore.kernel.org/all/20241119174954.1219002-1-quic_wasimn@quicinc.com/
> 
> v3:
>   - Fix RB8 board compatible string.
>   - v2: https://lore.kernel.org/all/20241115225152.3264396-1-quic_wasimn@quicinc.com/
> 
> v2:
>   - Remove unused dp nodes & update commit for ride vs ride-r3.
>   - v1: https://lore.kernel.org/all/20241110145339.3635437-1-quic_wasimn@quicinc.com/
> 
> Manaf Meethalavalappu Pallikunhi (1):
>   arm64: dts: qcom: Enable cpu cooling devices for QCS9075 platforms
> 
> Wasim Nazir (5):
>   dt-bindings: arm: qcom,ids: add SoC ID for QCS9075
>   soc: qcom: socinfo: add QCS9075 SoC ID
>   dt-bindings: arm: qcom: Document rb8/ride/ride-r3 on QCS9075
>   arm64: dts: qcom: Add support for QCS9075 RB8
>   arm64: dts: qcom: Add support for QCS9075 Ride & Ride-r3
> 
>  .../devicetree/bindings/arm/qcom.yaml         |   9 +
>  arch/arm64/boot/dts/qcom/Makefile             |   3 +
>  arch/arm64/boot/dts/qcom/qcs9075-rb8.dts      | 282 +++++++++++++++++
>  arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts  |  47 +++
>  arch/arm64/boot/dts/qcom/qcs9075-ride.dts     |  47 +++
>  arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi | 287 ++++++++++++++++++
>  drivers/soc/qcom/socinfo.c                    |   1 +
>  include/dt-bindings/arm/qcom,ids.h            |   1 +
>  8 files changed, 677 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-rb8.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-thermal.dtsi
> 
> 
> base-commit: 8155b4ef3466f0e289e8fcc9e6e62f3f4dceeac2
> --
> 2.47.0
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


New warnings running 'make CHECK_DTBS=y qcom/qcs9075-rb8.dtb qcom/qcs9075-ride-r3.dtb qcom/qcs9075-ride.dtb' for 20241229152332.3068172-1-quic_wasimn@quicinc.com:

arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: qcom,gpi-dma@800000: $nodename:0: 'qcom,gpi-dma@800000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: qcom,gpi-dma@800000: $nodename:0: 'qcom,gpi-dma@800000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: qcom,gpi-dma@800000: $nodename:0: 'qcom,gpi-dma@800000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: bluetooth: 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: bluetooth: 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: bluetooth: 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: bluetooth: 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: bluetooth: 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: bluetooth: 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: qcom,gpi-dma@900000: $nodename:0: 'qcom,gpi-dma@900000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: qcom,gpi-dma@900000: $nodename:0: 'qcom,gpi-dma@900000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: qcom,gpi-dma@900000: $nodename:0: 'qcom,gpi-dma@900000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: qcom,gpi-dma@a00000: $nodename:0: 'qcom,gpi-dma@a00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: qcom,gpi-dma@a00000: $nodename:0: 'qcom,gpi-dma@a00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: qcom,gpi-dma@a00000: $nodename:0: 'qcom,gpi-dma@a00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: qcom,gpi-dma@b00000: $nodename:0: 'qcom,gpi-dma@b00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: qcom,gpi-dma@b00000: $nodename:0: 'qcom,gpi-dma@b00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: qcom,gpi-dma@b00000: $nodename:0: 'qcom,gpi-dma@b00000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: crypto@1dfa000: compatible: 'oneOf' conditional failed, one must be fixed:
	['qcom,sa8775p-qce', 'qcom,qce'] is too long
	['qcom,sa8775p-qce', 'qcom,qce'] is too short
	'qcom,crypto-v5.1' was expected
	'qcom,crypto-v5.4' was expected
	'qcom,sa8775p-qce' is not one of ['qcom,ipq4019-qce', 'qcom,sm8150-qce']
	'qcom,sa8775p-qce' is not one of ['qcom,ipq6018-qce', 'qcom,ipq8074-qce', 'qcom,ipq9574-qce', 'qcom,msm8996-qce', 'qcom,qcm2290-qce', 'qcom,sdm845-qce', 'qcom,sm6115-qce']
	'qcom,ipq4019-qce' was expected
	'qcom,sm8150-qce' was expected
	from schema $id: http://devicetree.org/schemas/crypto/qcom-qce.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: crypto@1dfa000: compatible: 'oneOf' conditional failed, one must be fixed:
	['qcom,sa8775p-qce', 'qcom,qce'] is too long
	['qcom,sa8775p-qce', 'qcom,qce'] is too short
	'qcom,crypto-v5.1' was expected
	'qcom,crypto-v5.4' was expected
	'qcom,sa8775p-qce' is not one of ['qcom,ipq4019-qce', 'qcom,sm8150-qce']
	'qcom,sa8775p-qce' is not one of ['qcom,ipq6018-qce', 'qcom,ipq8074-qce', 'qcom,ipq9574-qce', 'qcom,msm8996-qce', 'qcom,qcm2290-qce', 'qcom,sdm845-qce', 'qcom,sm6115-qce']
	'qcom,ipq4019-qce' was expected
	'qcom,sm8150-qce' was expected
	from schema $id: http://devicetree.org/schemas/crypto/qcom-qce.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: crypto@1dfa000: compatible: 'oneOf' conditional failed, one must be fixed:
	['qcom,sa8775p-qce', 'qcom,qce'] is too long
	['qcom,sa8775p-qce', 'qcom,qce'] is too short
	'qcom,crypto-v5.1' was expected
	'qcom,crypto-v5.4' was expected
	'qcom,sa8775p-qce' is not one of ['qcom,ipq4019-qce', 'qcom,sm8150-qce']
	'qcom,sa8775p-qce' is not one of ['qcom,ipq6018-qce', 'qcom,ipq8074-qce', 'qcom,ipq9574-qce', 'qcom,msm8996-qce', 'qcom,qcm2290-qce', 'qcom,sdm845-qce', 'qcom,sm6115-qce']
	'qcom,ipq4019-qce' was expected
	'qcom,sm8150-qce' was expected
	from schema $id: http://devicetree.org/schemas/crypto/qcom-qce.yaml#
arch/arm64/boot/dts/qcom/qcs9075-rb8.dtb: rsc@18200000: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: rsc@18200000: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: rsc@18200000: 'power-domains' is a required property
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: ethernet@23000000: tx-queues-config: 'snps,tx-sched-sp' does not match any of the regexes: '^queue[0-9]$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: ethernet@23000000: Unevaluated properties are not allowed ('interconnect-names', 'interconnects', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: ethernet@23000000: tx-queues-config: 'snps,tx-sched-sp' does not match any of the regexes: '^queue[0-9]$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: ethernet@23000000: Unevaluated properties are not allowed ('interconnect-names', 'interconnects', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: ethernet@23040000: tx-queues-config: 'snps,tx-sched-sp' does not match any of the regexes: '^queue[0-9]$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: ethernet@23040000: Unevaluated properties are not allowed ('interconnect-names', 'interconnects', 'mdio', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: ethernet@23040000: tx-queues-config: 'snps,tx-sched-sp' does not match any of the regexes: '^queue[0-9]$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: ethernet@23040000: Unevaluated properties are not allowed ('interconnect-names', 'interconnects', 'mdio', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: wcn6855-pmu: 'vddpmumx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dtb: wcn6855-pmu: 'vddpmucx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: wcn6855-pmu: 'vddpmumx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/qcs9075-ride.dtb: wcn6855-pmu: 'vddpmucx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#

Re: (subset) [PATCH v5 0/6] arm64: qcom: Add support for QCS9075 boards

[Bjorn Andersson]

On Sun, 29 Dec 2024 20:53:26 +0530, Wasim Nazir wrote:
> This series:
> 
> Add support for Qualcomm's rb8, ride/ride-r3 boards using QCS9075 SoC.
> 
> QCS9075 is compatible IoT-industrial grade variant of SA8775p SoC.
> Unlike QCS9100, it doesn't have safety monitoring feature of
> Safety-Island(SAIL) subsystem, which affects thermal management.
> 
> [...]

Applied, thanks!

[1/6] dt-bindings: arm: qcom,ids: add SoC ID for QCS9075
      commit: cee3947b1aed42f71f99ce4e5d1410ee8670621a
[2/6] soc: qcom: socinfo: add QCS9075 SoC ID
      commit: 7b115b623545650407e3f262ee9cdd8a778a9fdf

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>