[PATCH v3 0/2] Initial support for the QCM6490 IDP

[PATCH v3 0/2] Initial support for the QCM6490 IDP

[Komal Bajaj]

Add dt-binding and devicetree files for QCM6490 IDP.

This patch depends-on:
https://lore.kernel.org/lkml/20230919-fp5-initial-v2-0-14bb7cedadf5@fairphone.com/

----
Changes from v2:
* Sorted nodes alphabetically
* Link to v2: https://lore.kernel.org/all/20231003055655.30994-1-quic_kbajaj@quicinc.com/

Changes from v1:
* Dropped suffix platform from model name
* Removed few nodes as they were identical to ones in sc7280
* Specified regulator-initial-mode property to vregs
* Dropped deletion of lpass and swr nodes
* Link to v1: https://lore.kernel.org/lkml/20230928133312.11371-1-quic_kbajaj@quicinc.com/

---
Komal Bajaj (2):
  dt-bindings: arm: qcom: Add QCM6490 IDP board
  arm64: dts: qcom: qcm6490: Add qcm6490 dts file

 .../devicetree/bindings/arm/qcom.yaml         |   1 +
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 arch/arm64/boot/dts/qcom/qcm6490-idp.dts      | 335 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/qcm6490.dtsi         |  94 +++++
 4 files changed, 431 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcm6490.dtsi

--
2.42.0

[PATCH v3 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP board

[Komal Bajaj]

Document the qcom,qcm6490-idp board based off qcm6490 SoC.

Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 76934f4772e9..87068d6c042d 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -395,6 +395,7 @@ properties:
       - items:
           - enum:
               - fairphone,fp5
+              - qcom,qcm6490-idp
           - const: qcom,qcm6490

       - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
--
2.42.0

[PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Komal Bajaj]

Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
platform. QCM6490 is derived from SC7280 meant for various
form factor including IoT.

Supported features are, as of now:
* Debug UART
* eMMC
* USB

Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
---
 arch/arm64/boot/dts/qcom/Makefile        |   1 +
 arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 333 +++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/qcm6490.dtsi    |  94 +++++++
 3 files changed, 428 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/qcm6490.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 73c3be0f8872..3a2d9dbaacce 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-maple.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-poplar.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-xiaomi-sagit.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-fairphone-fp5.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
new file mode 100644
index 000000000000..d81a7810fd5a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "pm7325.dtsi"
+#include "pm8350c.dtsi"
+#include "pmk8350.dtsi"
+#include "qcm6490.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. QCM6490 IDP";
+	compatible = "qcom,qcm6490-idp", "qcom,qcm6490";
+
+	aliases {
+		serial0 = &uart5;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm7325-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vreg_s1b_1p8: smps1 {
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <2040000>;
+		};
+
+		vreg_s7b_0p9: smps7 {
+			regulator-min-microvolt = <535000>;
+			regulator-max-microvolt = <1120000>;
+		};
+
+		vreg_s8b_1p2: smps8 {
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1500000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
+		};
+
+		vreg_l1b_0p8: ldo1 {
+			regulator-min-microvolt = <825000>;
+			regulator-max-microvolt = <925000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2b_3p0: ldo2 {
+			regulator-min-microvolt = <2700000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6b_1p2: ldo6 {
+			regulator-min-microvolt = <1140000>;
+			regulator-max-microvolt = <1260000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7b_2p9: ldo7 {
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8b_0p9: ldo8 {
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <970000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9b_1p2: ldo9 {
+			regulator-min-microvolt = <1080000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11b_1p7: ldo11 {
+			regulator-min-microvolt = <1504000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12b_0p8: ldo12 {
+			regulator-min-microvolt = <751000>;
+			regulator-max-microvolt = <824000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13b_0p8: ldo13 {
+			regulator-min-microvolt = <530000>;
+			regulator-max-microvolt = <824000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14b_1p2: ldo14 {
+			regulator-min-microvolt = <1080000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15b_0p8: ldo15 {
+			regulator-min-microvolt = <765000>;
+			regulator-max-microvolt = <1020000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16b_1p2: ldo16 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17b_1p8: ldo17 {
+			regulator-min-microvolt = <1700000>;
+			regulator-max-microvolt = <1900000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l18b_1p8: ldo18 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l19b_1p8: ldo19 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pm8350c-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vreg_s1c_2p2: smps1 {
+			regulator-min-microvolt = <2190000>;
+			regulator-max-microvolt = <2210000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s9c_1p0: smps9 {
+			regulator-min-microvolt = <1010000>;
+			regulator-max-microvolt = <1170000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1c_1p8: ldo1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1980000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c_1p8: ldo2 {
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <1980000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c_3p0: ldo3 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3540000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4c_1p8: ldo4 {
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5c_1p8: ldo5 {
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6c_2p9: ldo6 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7c_3p0: ldo7 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8c_1p8: ldo8 {
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9c_2p9: ldo9 {
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10c_0p8: ldo10 {
+			regulator-min-microvolt = <720000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11c_2p8: ldo11 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12c_1p8: ldo12 {
+			regulator-min-microvolt = <1650000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13c_3p0: ldo13 {
+			regulator-min-microvolt = <2700000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_bob: bob {
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3960000>;
+		};
+	};
+};
+
+&gpi_dma0 {
+	status = "okay";
+};
+
+&gpi_dma1 {
+	status = "okay";
+};
+
+&pm8350c_pwm {
+	status = "okay";
+};
+
+&qup_uart5_rx {
+	drive-strength = <2>;
+	bias-pull-up;
+};
+
+&qup_uart5_tx {
+	drive-strength = <2>;
+	bias-disable;
+};
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sdc1_clk {
+	bias-disable;
+	drive-strength = <16>;
+};
+
+&sdc1_cmd {
+	bias-pull-up;
+	drive-strength = <10>;
+};
+
+&sdc1_data {
+	bias-pull-up;
+	drive-strength = <10>;
+};
+
+&sdc1_rclk {
+	bias-pull-down;
+};
+
+&sdhc_1 {
+	non-removable;
+	no-sd;
+	no-sdio;
+
+	vmmc-supply = <&vreg_l7b_2p9>;
+	vqmmc-supply = <&vreg_l19b_1p8>;
+
+	status = "okay";
+};
+
+&uart5 {
+	compatible = "qcom,geni-debug-uart";
+	status = "okay";
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_1_dwc3 {
+	dr_mode = "peripheral";
+};
+
+&usb_1_hsphy {
+	vdda-pll-supply = <&vreg_l10c_0p8>;
+	vdda33-supply = <&vreg_l2b_3p0>;
+	vdda18-supply = <&vreg_l1c_1p8>;
+	qcom,hs-rise-fall-time-bp = <0>;
+	qcom,squelch-detector-bp = <(-2090)>;
+	qcom,hs-disconnect-bp = <1743>;
+	qcom,hs-amplitude-bp = <1780>;
+	qcom,hs-crossover-voltage-microvolt = <(-31000)>;
+	qcom,hs-output-impedance-micro-ohms = <2600000>;
+
+	status = "okay";
+};
+
+&usb_1_qmpphy {
+	vdda-phy-supply = <&vreg_l6b_1p2>;
+	vdda-pll-supply = <&vreg_l1b_0p8>;
+
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
new file mode 100644
index 000000000000..b93270cae9ae
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "sc7280.dtsi"
+
+/*
+ * Delete unused sc7280 memory nodes and define the memory regions
+ * required by qcm6490
+ */
+/delete-node/ &rmtfs_mem;
+/delete-node/ &wlan_ce_mem;
+
+/{
+	reserved-memory {
+		cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
+			reg = <0x0 0x81800000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		camera_mem: camera@84300000 {
+			reg = <0x0 0x84300000 0x0 0x500000>;
+			no-map;
+		};
+
+		wpss_mem: wpss@0x84800000 {
+			reg = <0x0 0x84800000 0x0 0x1900000>;
+			no-map;
+		};
+
+		adsp_mem: adsp@86100000 {
+			reg = <0x0 0x86100000 0x0 0x2800000>;
+			no-map;
+		};
+
+		cdsp_mem: cdsp@88900000 {
+			reg = <0x0 0x88900000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		cvp_mem: cvp@8ac00000 {
+			reg = <0x0 0x8ac00000 0x0 0x500000>;
+			no-map;
+		};
+
+		ipa_gsi_mem: ipa-gsi@8b110000 {
+			reg = <0x0 0x8b110000 0x0 0xa000>;
+			no-map;
+		};
+
+		gpu_microcode_mem: gpu-microcode@8b11a000 {
+			reg = <0x0 0x8b11a000 0x0 0x2000>;
+			no-map;
+		};
+
+		mpss_mem: mpss@8b800000 {
+			reg = <0x0 0x8b800000 0x0 0xf600000>;
+			no-map;
+		};
+
+		tz_stat_mem: tz-stat@c0000000 {
+			reg = <0x0 0xc0000000 0x0 0x100000>;
+			no-map;
+		};
+
+		tags_mem: tags@c0100000 {
+			reg = <0x0 0xc0100000 0x0 0x1200000>;
+			no-map;
+		};
+
+		qtee_mem: qtee@c1300000 {
+			reg = <0x0 0xc1300000 0x0 0x500000>;
+			no-map;
+		};
+
+		trusted_apps_mem: trusted_apps@c1800000 {
+			reg = <0x0 0xc1800000 0x0 0x3900000>;
+			no-map;
+		};
+	};
+};
+
+&video_mem {
+	reg = <0x0 0x8a700000 0x0 0x500000>;
+};
+
+&wifi {
+	memory-region = <&wlan_fw_mem>;
+};
+
+&xbl_mem {
+	reg = <0x0 0x80700000 0x0 0x100000>;
+};
--
2.42.0

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Krzysztof Kozlowski]

On 03/10/2023 19:54, Komal Bajaj wrote:
> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
> platform. QCM6490 is derived from SC7280 meant for various
> form factor including IoT.
> 
> Supported features are, as of now:
> * Debug UART
> * eMMC
> * USB
> 
> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[kernel test robot]

Hi Komal,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20231003]
[cannot apply to robh/for-next v6.6-rc4 v6.6-rc3 v6.6-rc2 linus/master v6.6-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Komal-Bajaj/dt-bindings-arm-qcom-Add-QCM6490-IDP-board/20231004-015725
base:   next-20231003
patch link:    https://lore.kernel.org/r/20231003175456.14774-3-quic_kbajaj%40quicinc.com
patch subject: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231006/202310062256.LQAdaNZV-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231006/202310062256.LQAdaNZV-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202310062256.LQAdaNZV-lkp@intel.com/

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/qcom/pm7325.dtsi:9.11-33.3 Label or path spmi_bus not found
>> Error: arch/arm64/boot/dts/qcom/pm7325.dtsi:35.1-15 Label or path thermal_zones not found
>> Error: arch/arm64/boot/dts/qcom/pm8350c.dtsi:9.1-10 Label or path spmi_bus not found
>> Error: arch/arm64/boot/dts/qcom/pmk8350.dtsi:26.1-10 Label or path spmi_bus not found
>> Error: arch/arm64/boot/dts/qcom/qcm6490-idp.dts:249.1-13 Label or path pm8350c_pwm not found
   FATAL ERROR: Syntax error parsing input tree

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Konrad Dybcio]

On 3.10.2023 19:54, Komal Bajaj wrote:
> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
> platform. QCM6490 is derived from SC7280 meant for various
> form factor including IoT.
> 
> Supported features are, as of now:
> * Debug UART
> * eMMC
> * USB
> 
> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
> ---
[...]

> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
> new file mode 100644
> index 000000000000..b93270cae9ae
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "sc7280.dtsi"
> +
> +/*
> + * Delete unused sc7280 memory nodes and define the memory regions
> + * required by qcm6490
> + */
> +/delete-node/ &rmtfs_mem;
> +/delete-node/ &wlan_ce_mem;
> +
> +/{
> +	reserved-memory {
> +		cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
> +			reg = <0x0 0x81800000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		camera_mem: camera@84300000 {
Uhh.. this is totally not the same memory map that I have on a
random msm-5.4 source+devicetree drop (which does in turn align
with the one on QCM6490 Fairphone 5, as it should because it's
a rebadged reference device for the most part)..

Did you guys *really* redo it between software releases?

This SoC family has been on the market for quite some time,
breaking software expectations like that is not cool, especially
on a product with a promised lifespan of 10 years or whatever!

With that, this really seems more of a change that would belong
in the IDP dts than the 6490-common one..

Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Konrad Dybcio]

On 3.10.2023 19:54, Komal Bajaj wrote:
> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
> platform. QCM6490 is derived from SC7280 meant for various
> form factor including IoT.
> 
> Supported features are, as of now:
> * Debug UART
> * eMMC
> * USB
> 
> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile        |   1 +
>  arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 333 +++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/qcm6490.dtsi    |  94 +++++++
>  3 files changed, 428 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/qcm6490.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 73c3be0f8872..3a2d9dbaacce 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-maple.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-poplar.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-xiaomi-sagit.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-fairphone-fp5.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-idp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> new file mode 100644
> index 000000000000..d81a7810fd5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "pm7325.dtsi"
> +#include "pm8350c.dtsi"
> +#include "pmk8350.dtsi"
> +#include "qcm6490.dtsi"
As the kernel robot pointed out, this has clearly not even been
compile-tested..

Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Mukesh Ojha]

On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
> On 3.10.2023 19:54, Komal Bajaj wrote:
>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>> platform. QCM6490 is derived from SC7280 meant for various
>> form factor including IoT.
>>
>> Supported features are, as of now:
>> * Debug UART
>> * eMMC
>> * USB
>>
>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>> ---
> [...]
> 
>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>> new file mode 100644
>> index 000000000000..b93270cae9ae
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>> @@ -0,0 +1,94 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include "sc7280.dtsi"
>> +
>> +/*
>> + * Delete unused sc7280 memory nodes and define the memory regions
>> + * required by qcm6490
>> + */
>> +/delete-node/ &rmtfs_mem;
>> +/delete-node/ &wlan_ce_mem;
>> +
>> +/{
>> +	reserved-memory {
>> +		cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>> +			reg = <0x0 0x81800000 0x0 0x1e00000>;
>> +			no-map;
>> +		};
>> +
>> +		camera_mem: camera@84300000 {
> Uhh.. this is totally not the same memory map that I have on a
> random msm-5.4 source+devicetree drop (which does in turn align
> with the one on QCM6490 Fairphone 5, as it should because it's
> a rebadged reference device for the most part)..
> 
> Did you guys *really* redo it between software releases?

QCM6490 fairphone is special case where same SOC is used for mobile
product and it uses sc7280 memory map.

Current patch adds support for the same SOC marketed for IOT segment
[1] and very active in the development and soon going to freeze its
memory map, so we are deriving memory map from sc7280 and creating
a new memory map for all IOT product with qcm6490.dtsi .

[1]
https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490

> 
> This SoC family has been on the market for quite some time,
> breaking software expectations like that is not cool, especially
> on a product with a promised lifespan of 10 years or whatever!

I agree, but we are not changing anything for product which are there
in the market instead defining a new memory map what is going to come
with qcm6490.dtsi for IOT. Sorry, the other qcm6490 soc with
fairphone(for mobile) can get confuse with qcm6490.dtsi but that
is special case and i hope, that should be fine but, let me know if
there is concern.
> 
> With that, this really seems more of a change that would belong
> in the IDP dts than the 6490-common one..


We wanted to keep it in qcm6490.dtsi as there are some more product
going to share this in future.

-Mukesh

> 
> Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Konrad Dybcio]

On 10/11/23 07:40, Mukesh Ojha wrote:
> 
> 
> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>> platform. QCM6490 is derived from SC7280 meant for various
>>> form factor including IoT.
>>>
>>> Supported features are, as of now:
>>> * Debug UART
>>> * eMMC
>>> * USB
>>>
>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>> ---
>> [...]
>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi 
>>> b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>> new file mode 100644
>>> index 000000000000..b93270cae9ae
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>> @@ -0,0 +1,94 @@
>>> +// SPDX-License-Identifier: BSD-3-Clause
>>> +/*
>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
>>> reserved.
>>> + */
>>> +
>>> +#include "sc7280.dtsi"
>>> +
>>> +/*
>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>> + * required by qcm6490
>>> + */
>>> +/delete-node/ &rmtfs_mem;
>>> +/delete-node/ &wlan_ce_mem;
>>> +
>>> +/{
>>> +    reserved-memory {
>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>> +            no-map;
>>> +        };
>>> +
>>> +        camera_mem: camera@84300000 {
>> Uhh.. this is totally not the same memory map that I have on a
>> random msm-5.4 source+devicetree drop (which does in turn align
>> with the one on QCM6490 Fairphone 5, as it should because it's
>> a rebadged reference device for the most part)..
>>
>> Did you guys *really* redo it between software releases?
> 
> QCM6490 fairphone is special case where same SOC is used for mobile
> product and it uses sc7280 memory map.
> 
> Current patch adds support for the same SOC marketed for IOT segment
> [1] and very active in the development and soon going to freeze its
> memory map, so we are deriving memory map from sc7280 and creating
> a new memory map for all IOT product with qcm6490.dtsi .
Stop reinventing the wheel. I'm not going to accept patches that are 
supposed to define ABI for products that are still in development.
Not unless Qualcomm changes their attitude towards unilaterally breaking 
things for no good reason.

> 
> [1]
> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
> 
>>
>> This SoC family has been on the market for quite some time,
>> breaking software expectations like that is not cool, especially
>> on a product with a promised lifespan of 10 years or whatever!
> 
> I agree, but we are not changing anything for product which are there
> in the market instead defining a new memory map what is going to come
> with qcm6490.dtsi for IOT.
Why would the OS care about the market segment you're targeting?
Why would the firmware you're building care about the market segment 
you're targeting? The LE vs LA vs LU vs WP vs whatever split is so 
unnecessary and arbitrary on the firmware/kernel side..

The firmware should either be fully relocatable (so that dynamic memory 
reservation can be used), unified so that there's no changes or better 
yet stored in separate memory so that q6 cores don't steal the RAM that 
the user paid for and you can do whatever ugly magic you please in there.

This arbitrary segmentation makes it impossible to have a common base, 
or to explain what device should go where to a newcomer.

Sorry, the other qcm6490 soc with
> fairphone(for mobile) can get confuse with qcm6490.dtsi but that
> is special case and i hope, that should be fine but, let me know if
> there is concern.
>>
>> With that, this really seems more of a change that would belong
>> in the IDP dts than the 6490-common one..
> 
> 
> We wanted to keep it in qcm6490.dtsi as there are some more product
> going to share this in future.
And then what if you decide that you need to re-release SC7280 for 
automotive and make changes again? Do we define qcm6490au.dtsi which 
will redefine everything again-again?

Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Mukesh Ojha]

On 10/11/2023 3:17 PM, Konrad Dybcio wrote:
> 
> 
> On 10/11/23 07:40, Mukesh Ojha wrote:
>>
>>
>> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>>> platform. QCM6490 is derived from SC7280 meant for various
>>>> form factor including IoT.
>>>>
>>>> Supported features are, as of now:
>>>> * Debug UART
>>>> * eMMC
>>>> * USB
>>>>
>>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>>> ---
>>> [...]
>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi 
>>>> b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>> new file mode 100644
>>>> index 000000000000..b93270cae9ae
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>> @@ -0,0 +1,94 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
>>>> reserved.
>>>> + */
>>>> +
>>>> +#include "sc7280.dtsi"
>>>> +
>>>> +/*
>>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>>> + * required by qcm6490
>>>> + */
>>>> +/delete-node/ &rmtfs_mem;
>>>> +/delete-node/ &wlan_ce_mem;
>>>> +
>>>> +/{
>>>> +    reserved-memory {
>>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        camera_mem: camera@84300000 {
>>> Uhh.. this is totally not the same memory map that I have on a
>>> random msm-5.4 source+devicetree drop (which does in turn align
>>> with the one on QCM6490 Fairphone 5, as it should because it's
>>> a rebadged reference device for the most part)..
>>>
>>> Did you guys *really* redo it between software releases?
>>
>> QCM6490 fairphone is special case where same SOC is used for mobile
>> product and it uses sc7280 memory map.
>>
>> Current patch adds support for the same SOC marketed for IOT segment
>> [1] and very active in the development and soon going to freeze its
>> memory map, so we are deriving memory map from sc7280 and creating
>> a new memory map for all IOT product with qcm6490.dtsi .
> Stop reinventing the wheel. I'm not going to accept patches that are 
> supposed to define ABI for products that are still in development.
> Not unless Qualcomm changes their attitude towards unilaterally breaking 
> things for no good reason.
> 
>>
>> [1]
>> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
>>
>>>
>>> This SoC family has been on the market for quite some time,
>>> breaking software expectations like that is not cool, especially
>>> on a product with a promised lifespan of 10 years or whatever!
>>
>> I agree, but we are not changing anything for product which are there
>> in the market instead defining a new memory map what is going to come
>> with qcm6490.dtsi for IOT.
> Why would the OS care about the market segment you're targeting?
> Why would the firmware you're building care about the market segment 
> you're targeting? The LE vs LA vs LU vs WP vs whatever split is so 
> unnecessary and arbitrary on the firmware/kernel side..

Forgive me, if i ask some very basic question, just trying to put my
thought,

I agree, OS should not worry about the market segment, but through the
DT firmware, we can better optimize memory to either give more memory to
user or give more memory to certain DSP's to enable certain feature 
through the firmware like some logging infra etc., and due to which
certain gaps can get created where certain memory region need to be
move up or down due to increase in the carve-out.

Let's say X Soc released with some memory map, any derivative SoC Y
should follow X's memory map if it is including X dtsi ? and the reason 
why Y want to include X is solely the work done for X and most of 
peripheral memory addresses is matching.

But 'Y' could be different product, right? and it could have different
firmware and it is not like 'X' firmware will run on 'Y' ?

Now a days, most of our firmware are relocatable.

-Mukesh
> 
> The firmware should either be fully relocatable (so that dynamic memory 
> reservation can be used), unified so that there's no changes or better 
> yet stored in separate memory so that q6 cores don't steal the RAM that 
> the user paid for and you can do whatever ugly magic you please in there.
> 
> This arbitrary segmentation makes it impossible to have a common base, 
> or to explain what device should go where to a newcomer.
> 
> Sorry, the other qcm6490 soc with
>> fairphone(for mobile) can get confuse with qcm6490.dtsi but that
>> is special case and i hope, that should be fine but, let me know if
>> there is concern.
>>>
>>> With that, this really seems more of a change that would belong
>>> in the IDP dts than the 6490-common one..
>>
>>
>> We wanted to keep it in qcm6490.dtsi as there are some more product
>> going to share this in future.
> And then what if you decide that you need to re-release SC7280 for 
> automotive and make changes again? Do we define qcm6490au.dtsi which 
> will redefine everything again-again?
> 
> Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Trilok Soni]

On 10/11/2023 2:47 AM, Konrad Dybcio wrote:
> 
> 
> On 10/11/23 07:40, Mukesh Ojha wrote:
>>
>>
>> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>>> platform. QCM6490 is derived from SC7280 meant for various
>>>> form factor including IoT.
>>>>
>>>> Supported features are, as of now:
>>>> * Debug UART
>>>> * eMMC
>>>> * USB
>>>>
>>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>>> ---
>>> [...]
>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>> new file mode 100644
>>>> index 000000000000..b93270cae9ae
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>> @@ -0,0 +1,94 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + */
>>>> +
>>>> +#include "sc7280.dtsi"
>>>> +
>>>> +/*
>>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>>> + * required by qcm6490
>>>> + */
>>>> +/delete-node/ &rmtfs_mem;
>>>> +/delete-node/ &wlan_ce_mem;
>>>> +
>>>> +/{
>>>> +    reserved-memory {
>>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>>> +            no-map;
>>>> +        };
>>>> +
>>>> +        camera_mem: camera@84300000 {
>>> Uhh.. this is totally not the same memory map that I have on a
>>> random msm-5.4 source+devicetree drop (which does in turn align
>>> with the one on QCM6490 Fairphone 5, as it should because it's
>>> a rebadged reference device for the most part)..
>>>
>>> Did you guys *really* redo it between software releases?
>>
>> QCM6490 fairphone is special case where same SOC is used for mobile
>> product and it uses sc7280 memory map.
>>
>> Current patch adds support for the same SOC marketed for IOT segment
>> [1] and very active in the development and soon going to freeze its
>> memory map, so we are deriving memory map from sc7280 and creating
>> a new memory map for all IOT product with qcm6490.dtsi .
> Stop reinventing the wheel. I'm not going to accept patches that are supposed to define ABI for products that are still in development.
> Not unless Qualcomm changes their attitude towards unilaterally breaking things for no good reason.
> 
>>
>> [1]
>> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
>>
>>>
>>> This SoC family has been on the market for quite some time,
>>> breaking software expectations like that is not cool, especially
>>> on a product with a promised lifespan of 10 years or whatever!
>>
>> I agree, but we are not changing anything for product which are there
>> in the market instead defining a new memory map what is going to come
>> with qcm6490.dtsi for IOT.
> Why would the OS care about the market segment you're targeting?
> Why would the firmware you're building care about the market segment you're targeting? The LE vs LA vs LU vs WP vs whatever split is so unnecessary and arbitrary on the firmware/kernel side..
> 
> The firmware should either be fully relocatable (so that dynamic memory reservation can be used), unified so that there's no changes or better yet stored in separate memory so that q6 cores don't steal the RAM that the user paid for and you can do whatever ugly magic you please in there.
> 
> This arbitrary segmentation makes it impossible to have a common base, or to explain what device should go where to a newcomer.

Konrad it is possible to use the same SOC with the multiple segments w/ the different memory maps. 

Memory map here is how you organize the DDR and give it to various S/W and DSP regions etc; 

Also these SOCs are around for sometime and it is possible that new segments may use it. We can't solve
or know all the new segments need when the SOCs come out. Memory maps does provide that flexibility
and they don't change often. OEMs has also some flexibility to change the memory map if needed to optimize. 

This SOC is around for quite sometime new usecases are expected to emerge. I don't see it as
way to stop us from taking these contributions into the linux-arm-msm. 

---Trilok Soni


-- 
---Trilok Soni

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Konrad Dybcio]

On 10/11/23 15:40, Mukesh Ojha wrote:
> 
> 
> On 10/11/2023 3:17 PM, Konrad Dybcio wrote:
>>
>>
>> On 10/11/23 07:40, Mukesh Ojha wrote:
>>>
>>>
>>> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>>>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>>>> platform. QCM6490 is derived from SC7280 meant for various
>>>>> form factor including IoT.
>>>>>
>>>>> Supported features are, as of now:
>>>>> * Debug UART
>>>>> * eMMC
>>>>> * USB
>>>>>
>>>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>>>> ---
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi 
>>>>> b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>> new file mode 100644
>>>>> index 000000000000..b93270cae9ae
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>> @@ -0,0 +1,94 @@
>>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>>> +/*
>>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
>>>>> reserved.
>>>>> + */
>>>>> +
>>>>> +#include "sc7280.dtsi"
>>>>> +
>>>>> +/*
>>>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>>>> + * required by qcm6490
>>>>> + */
>>>>> +/delete-node/ &rmtfs_mem;
>>>>> +/delete-node/ &wlan_ce_mem;
>>>>> +
>>>>> +/{
>>>>> +    reserved-memory {
>>>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        camera_mem: camera@84300000 {
>>>> Uhh.. this is totally not the same memory map that I have on a
>>>> random msm-5.4 source+devicetree drop (which does in turn align
>>>> with the one on QCM6490 Fairphone 5, as it should because it's
>>>> a rebadged reference device for the most part)..
>>>>
>>>> Did you guys *really* redo it between software releases?
>>>
>>> QCM6490 fairphone is special case where same SOC is used for mobile
>>> product and it uses sc7280 memory map.
>>>
>>> Current patch adds support for the same SOC marketed for IOT segment
>>> [1] and very active in the development and soon going to freeze its
>>> memory map, so we are deriving memory map from sc7280 and creating
>>> a new memory map for all IOT product with qcm6490.dtsi .
>> Stop reinventing the wheel. I'm not going to accept patches that are 
>> supposed to define ABI for products that are still in development.
>> Not unless Qualcomm changes their attitude towards unilaterally 
>> breaking things for no good reason.
>>
>>>
>>> [1]
>>> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
>>>
>>>>
>>>> This SoC family has been on the market for quite some time,
>>>> breaking software expectations like that is not cool, especially
>>>> on a product with a promised lifespan of 10 years or whatever!
>>>
>>> I agree, but we are not changing anything for product which are there
>>> in the market instead defining a new memory map what is going to come
>>> with qcm6490.dtsi for IOT.
>> Why would the OS care about the market segment you're targeting?
>> Why would the firmware you're building care about the market segment 
>> you're targeting? The LE vs LA vs LU vs WP vs whatever split is so 
>> unnecessary and arbitrary on the firmware/kernel side..
First of all, I vented off on you very heavily in response to seeing 
something I don't like, even though you didn't have anything to do with 
it. Please accept my apology.

There are some difficulties with integrating certain things upstream to 
work out on a broader scale, but me screaming at engineers in public 
won't help much with that.

> Forgive me, if i ask some very basic question, just trying to put my
> thought,
> 
> I agree, OS should not worry about the market segment, but through the
> DT firmware, we can better optimize memory to either give more memory to
> user or give more memory to certain DSP's to enable certain feature 
> through the firmware like some logging infra etc., and due to which
> certain gaps can get created where certain memory region need to be
> move up or down due to increase in the carve-out.
This is totally fine from a generic standpoint, however Qualcomm has a 
history (and you can see that in most SoC DTSIs) of having a common (or 
almost common) memory map on the vast majority of devices based on a 
given family of SoCs. We've been steadily taking advantage of that for 
quite some time.

Here, we have an established compute SoC (7280-Chrome) with a memory 
setup that roughly matches its mobile counterpart (6490-LA or 778G or 
whatever different derivatives).

IIUC you're tweaking the software for the "new IoT BSP" and resizing 
some regions resulted in many differences (as PIL regions tend to be 
contiguous one-to-another). The real issue here is that if we express 
this changed memory map in qcm6490.dtsi, all devices that have already 
shipped with the older-than-"new IoT BSP" software will differ rather 
significantly.

You mentioned that there are going to be multiple users of *this new* 
configuration, perhaps qcm6490-iot-common.dtsi (similar to 
sc7280-chrome-common.dtsi) could facilitate the new bsp changes instead, 
making it less ambiguous.
> 
> Let's say X Soc released with some memory map, any derivative SoC Y
> should follow X's memory map if it is including X dtsi ? and the reason 
> why Y want to include X is solely the work done for X and most of 
> peripheral memory addresses is matching.
> 
> But 'Y' could be different product, right? and it could have different
> firmware and it is not like 'X' firmware will run on 'Y' ?
Right, historically that hasn't happened very often but it could be like 
that.

> Now a days, most of our firmware are relocatable.
And we should totally take advantage of that. Stephan Gerhold has 
submitted some improvements that made it possible to dynamically 
allocate memory regions on 8916, this should probably be reused and 
expanded for other SoCs.  Would it be possible for you to try out 
dynamic PIL region allocation on this board? See [1] for example.


And the last thing is, I would like for you to give us some sort of a 
stability promise for this. You mentioned this SoC spin is "very active 
in the development", which makes me worried for DT compatibility with 
future METAs. We have unfortunately historically had to deal with 
different firmware packages behaving in divergent ways, and not always 
consistently between devices (but the last point may be just vendor 
modifications).

We are supposed to be able to boot any future version of Linux with this 
initial devicetree, unless there's some fatal flaw that needs 
retroactive fixing (like when we tried to express LLCC as a contiguous 
region instead of a set of slices up until 8550 release or so). Please 
have that in mind, we've tried so hard to keep this ABI-like.

And the last-last (I promise..) question, is this the final SoC silicon 
revision? And is it any different from the QCM6490 that has landed in 
some Android devices physically? Or does it simply ship with a different 
sw stack?

Konrad

[1] 
https://lore.kernel.org/linux-arm-msm/20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net/#t

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Konrad Dybcio]

On 10/11/23 19:35, Trilok Soni wrote:
> On 10/11/2023 2:47 AM, Konrad Dybcio wrote:
>>
>>
>> On 10/11/23 07:40, Mukesh Ojha wrote:
>>>
>>>
>>> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>>>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>>>> platform. QCM6490 is derived from SC7280 meant for various
>>>>> form factor including IoT.
>>>>>
>>>>> Supported features are, as of now:
>>>>> * Debug UART
>>>>> * eMMC
>>>>> * USB
>>>>>
>>>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>>>> ---
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>> new file mode 100644
>>>>> index 000000000000..b93270cae9ae
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>> @@ -0,0 +1,94 @@
>>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>>> +/*
>>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>>> + */
>>>>> +
>>>>> +#include "sc7280.dtsi"
>>>>> +
>>>>> +/*
>>>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>>>> + * required by qcm6490
>>>>> + */
>>>>> +/delete-node/ &rmtfs_mem;
>>>>> +/delete-node/ &wlan_ce_mem;
>>>>> +
>>>>> +/{
>>>>> +    reserved-memory {
>>>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>>>> +            no-map;
>>>>> +        };
>>>>> +
>>>>> +        camera_mem: camera@84300000 {
>>>> Uhh.. this is totally not the same memory map that I have on a
>>>> random msm-5.4 source+devicetree drop (which does in turn align
>>>> with the one on QCM6490 Fairphone 5, as it should because it's
>>>> a rebadged reference device for the most part)..
>>>>
>>>> Did you guys *really* redo it between software releases?
>>>
>>> QCM6490 fairphone is special case where same SOC is used for mobile
>>> product and it uses sc7280 memory map.
>>>
>>> Current patch adds support for the same SOC marketed for IOT segment
>>> [1] and very active in the development and soon going to freeze its
>>> memory map, so we are deriving memory map from sc7280 and creating
>>> a new memory map for all IOT product with qcm6490.dtsi .
>> Stop reinventing the wheel. I'm not going to accept patches that are supposed to define ABI for products that are still in development.
>> Not unless Qualcomm changes their attitude towards unilaterally breaking things for no good reason.
>>
>>>
>>> [1]
>>> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
>>>
>>>>
>>>> This SoC family has been on the market for quite some time,
>>>> breaking software expectations like that is not cool, especially
>>>> on a product with a promised lifespan of 10 years or whatever!
>>>
>>> I agree, but we are not changing anything for product which are there
>>> in the market instead defining a new memory map what is going to come
>>> with qcm6490.dtsi for IOT.
>> Why would the OS care about the market segment you're targeting?
>> Why would the firmware you're building care about the market segment you're targeting? The LE vs LA vs LU vs WP vs whatever split is so unnecessary and arbitrary on the firmware/kernel side..
>>
>> The firmware should either be fully relocatable (so that dynamic memory reservation can be used), unified so that there's no changes or better yet stored in separate memory so that q6 cores don't steal the RAM that the user paid for and you can do whatever ugly magic you please in there.
>>
>> This arbitrary segmentation makes it impossible to have a common base, or to explain what device should go where to a newcomer.
> 
> Konrad it is possible to use the same SOC with the multiple segments w/ the different memory maps.
> 
> Memory map here is how you organize the DDR and give it to various S/W and DSP regions etc;
> 
> Also these SOCs are around for sometime and it is possible that new segments may use it. We can't solve
> or know all the new segments need when the SOCs come out. Memory maps does provide that flexibility
> and they don't change often. OEMs has also some flexibility to change the memory map if needed to optimize.
> 
> This SOC is around for quite sometime new usecases are expected to emerge. I don't see it as
> way to stop us from taking these contributions into the linux-arm-msm.
Yes I was way too harsh *and* didn't even clearly say what made me 
upset, please see my reply at:

https://lore.kernel.org/linux-arm-msm/01c7a346-1e8b-1767-7594-c8adcd4823c3@quicinc.com/T/#m717a0f6f6759606870a1f8c1383bc65408d8de07

Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Komal Bajaj]

On 10/7/2023 5:03 AM, Konrad Dybcio wrote:
> On 3.10.2023 19:54, Komal Bajaj wrote:
>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>> platform. QCM6490 is derived from SC7280 meant for various
>> form factor including IoT.
>>
>> Supported features are, as of now:
>> * Debug UART
>> * eMMC
>> * USB
>>
>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile        |   1 +
>>   arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 333 +++++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/qcm6490.dtsi    |  94 +++++++
>>   3 files changed, 428 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>>   create mode 100644 arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index 73c3be0f8872..3a2d9dbaacce 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-maple.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-poplar.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-xiaomi-sagit.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-fairphone-fp5.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-idp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>> new file mode 100644
>> index 000000000000..d81a7810fd5a
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>> @@ -0,0 +1,333 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>> +#include "pm7325.dtsi"
>> +#include "pm8350c.dtsi"
>> +#include "pmk8350.dtsi"
>> +#include "qcm6490.dtsi"
> As the kernel robot pointed out, this has clearly not even been
> compile-tested..

Sorry for this.. I made this change as per the comment that I got to 
sort the
inclusion files in alphabetical order. Incremental build compilation 
wasn't able
to catch this error.
I will move qcm6490.dtsi file inclusion before pm* files inclusion.

Thanks
Komal

>
> Konrad

Re: [PATCH v3 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file

[Mukesh Ojha]

On 10/12/2023 4:25 AM, Konrad Dybcio wrote:
> 
> 
> On 10/11/23 15:40, Mukesh Ojha wrote:
>>
>>
>> On 10/11/2023 3:17 PM, Konrad Dybcio wrote:
>>>
>>>
>>> On 10/11/23 07:40, Mukesh Ojha wrote:
>>>>
>>>>
>>>> On 10/7/2023 5:02 AM, Konrad Dybcio wrote:
>>>>> On 3.10.2023 19:54, Komal Bajaj wrote:
>>>>>> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
>>>>>> platform. QCM6490 is derived from SC7280 meant for various
>>>>>> form factor including IoT.
>>>>>>
>>>>>> Supported features are, as of now:
>>>>>> * Debug UART
>>>>>> * eMMC
>>>>>> * USB
>>>>>>
>>>>>> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
>>>>>> ---
>>>>> [...]
>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490.dtsi 
>>>>>> b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>>> new file mode 100644
>>>>>> index 000000000000..b93270cae9ae
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
>>>>>> @@ -0,0 +1,94 @@
>>>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>>>> +/*
>>>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
>>>>>> reserved.
>>>>>> + */
>>>>>> +
>>>>>> +#include "sc7280.dtsi"
>>>>>> +
>>>>>> +/*
>>>>>> + * Delete unused sc7280 memory nodes and define the memory regions
>>>>>> + * required by qcm6490
>>>>>> + */
>>>>>> +/delete-node/ &rmtfs_mem;
>>>>>> +/delete-node/ &wlan_ce_mem;
>>>>>> +
>>>>>> +/{
>>>>>> +    reserved-memory {
>>>>>> +        cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
>>>>>> +            reg = <0x0 0x81800000 0x0 0x1e00000>;
>>>>>> +            no-map;
>>>>>> +        };
>>>>>> +
>>>>>> +        camera_mem: camera@84300000 {
>>>>> Uhh.. this is totally not the same memory map that I have on a
>>>>> random msm-5.4 source+devicetree drop (which does in turn align
>>>>> with the one on QCM6490 Fairphone 5, as it should because it's
>>>>> a rebadged reference device for the most part)..
>>>>>
>>>>> Did you guys *really* redo it between software releases?
>>>>
>>>> QCM6490 fairphone is special case where same SOC is used for mobile
>>>> product and it uses sc7280 memory map.
>>>>
>>>> Current patch adds support for the same SOC marketed for IOT segment
>>>> [1] and very active in the development and soon going to freeze its
>>>> memory map, so we are deriving memory map from sc7280 and creating
>>>> a new memory map for all IOT product with qcm6490.dtsi .
>>> Stop reinventing the wheel. I'm not going to accept patches that are 
>>> supposed to define ABI for products that are still in development.
>>> Not unless Qualcomm changes their attitude towards unilaterally 
>>> breaking things for no good reason.
>>>
>>>>
>>>> [1]
>>>> https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcm6490
>>>>
>>>>>
>>>>> This SoC family has been on the market for quite some time,
>>>>> breaking software expectations like that is not cool, especially
>>>>> on a product with a promised lifespan of 10 years or whatever!
>>>>
>>>> I agree, but we are not changing anything for product which are there
>>>> in the market instead defining a new memory map what is going to come
>>>> with qcm6490.dtsi for IOT.
>>> Why would the OS care about the market segment you're targeting?
>>> Why would the firmware you're building care about the market segment 
>>> you're targeting? The LE vs LA vs LU vs WP vs whatever split is so 
>>> unnecessary and arbitrary on the firmware/kernel side..
> First of all, I vented off on you very heavily in response to seeing 
> something I don't like, even though you didn't have anything to do with 
> it. Please accept my apology.

That's fine, Np..

> 
> There are some difficulties with integrating certain things upstream to 
> work out on a broader scale, but me screaming at engineers in public 
> won't help much with that.
> 
>> Forgive me, if i ask some very basic question, just trying to put my
>> thought,
>>
>> I agree, OS should not worry about the market segment, but through the
>> DT firmware, we can better optimize memory to either give more memory to
>> user or give more memory to certain DSP's to enable certain feature 
>> through the firmware like some logging infra etc., and due to which
>> certain gaps can get created where certain memory region need to be
>> move up or down due to increase in the carve-out.
> This is totally fine from a generic standpoint, however Qualcomm has a 
> history (and you can see that in most SoC DTSIs) of having a common (or 
> almost common) memory map on the vast majority of devices based on a 
> given family of SoCs. We've been steadily taking advantage of that for 
> quite some time.
> 
> Here, we have an established compute SoC (7280-Chrome) with a memory 
> setup that roughly matches its mobile counterpart (6490-LA or 778G or 
> whatever different derivatives).

I understand..

> 
> IIUC you're tweaking the software for the "new IoT BSP" and resizing 
> some regions resulted in many differences (as PIL regions tend to be 
> contiguous one-to-another).

This is correct. There are some other differences like cdsp/adsp support 
that we shall be pushing soon which sc7280 doesn't use.

> The real issue here is that if we express 
> this changed memory map in qcm6490.dtsi, all devices that have already 
> shipped with the older-than-"new IoT BSP" software will differ rather 
> significantly.

Yes, I see your point. Subjective to this product segment there may be 
other BSP related additions.

> You mentioned that there are going to be multiple users of *this new* 
> configuration, perhaps qcm6490-iot-common.dtsi (similar to 
> sc7280-chrome-common.dtsi) could facilitate the new bsp changes instead, 
> making it less ambiguous.

Yeah, so IIUC to avoid any ambiguity (like mentioned in your previous 
comment) this might be a better option.

>>
>> Let's say X Soc released with some memory map, any derivative SoC Y
>> should follow X's memory map if it is including X dtsi ? and the 
>> reason why Y want to include X is solely the work done for X and most 
>> of peripheral memory addresses is matching.
>>
>> But 'Y' could be different product, right? and it could have different
>> firmware and it is not like 'X' firmware will run on 'Y' ?
> Right, historically that hasn't happened very often but it could be like 
> that.

This is what we are looking for..

> 
>> Now a days, most of our firmware are relocatable.
> And we should totally take advantage of that. Stephan Gerhold has 
> submitted some improvements that made it possible to dynamically 
> allocate memory regions on 8916, this should probably be reused and 
> expanded for other SoCs.  Would it be possible for you to try out 
> dynamic PIL region allocation on this board? See [1] for example.

You mean adapting this qcm6490.dtsi change to dynamic region? Can we do 
that without touching sc7280.dtsi memory map itself.

> And the last thing is, I would like for you to give us some sort of a 
> stability promise for this. You mentioned this SoC spin is "very active 
> in the development", which makes me worried for DT compatibility with 
> future METAs. We have unfortunately historically had to deal with 
> different firmware packages behaving in divergent ways, and not always 
> consistently between devices (but the last point may be just vendor 
> modifications).

We are checking and will come back on this. Outside these BSP dependent 
things, don't see a challenge in maintaining SoC support compatibility.

> We are supposed to be able to boot any future version of Linux with this 
> initial devicetree, unless there's some fatal flaw that needs 
> retroactive fixing (like when we tried to express LLCC as a contiguous 
> region instead of a set of slices up until 8550 release or so). Please 
> have that in mind, we've tried so hard to keep this ABI-like.

Yes, the plan is to maintain this SoC on moving latest kernel tips.

> And the last-last (I promise..) question, is this the final SoC silicon 
> revision? And is it any different from the QCM6490 that has landed in 
> some Android devices physically? Or does it simply ship with a different 
> sw stack?

I am not aware of this. In case the SoC is revised then the support need 
to be extended for new revision as well maintaining compatibility for 
older one.

-Mukesh

> 
> Konrad
> 
> [1] 
> https://lore.kernel.org/linux-arm-msm/20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net/#t