[PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Parikshit Pareek]

Change in v5:
- Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective
  board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts.
  Took inputs from Shazad Hussain in this regard(John)
- Added more description of the board differences(John)
- Not including Reviewed-by for Krzysztof, because of the new changes to
  be reviewed.
- Removed Reported-by tag(John).

Changes in v4:
 - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board.
 - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on
   Qdrive3 board.
 - Added Reported-by tag for Shazad(for ufs and usb_1 node removals)

Changes in v3:
 - Added Acked-by tag (Krzysztof)
 - Renamed dtsi to sa8540p-adp.dtsi (John)
 - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John)
 - Added cover letter

change in v2:
- Make dt-binding patch as the first one in the patch set
- Add , after year 2022, in the license header

Initial version:
- Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board
  specific file sa8540p-adp-ride.dts.


Parikshit Pareek (3):
  dt-bindings: arm: qcom: Document additional sa8540p device
  arm64: dts: qcom: sa8295p: move common nodes to dtsi
  arm64: dts: qcom: introduce sa8540p-ride dts

 .../devicetree/bindings/arm/qcom.yaml         |   1 +
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts      | 528 +++++-------------
 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts |  71 +++
 .../{sa8295p-adp.dts => sa8540p-adp.dtsi}     | 133 -----
 5 files changed, 219 insertions(+), 515 deletions(-)
 rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%)
 create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts
 copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)

-- 
2.17.1

[PATCH v5 1/3] dt-bindings: arm: qcom: Document additional sa8540p device

[Parikshit Pareek]

Add the ADP ride device to the valid device compatibles found on the
sa8540p platform.

Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
Acked-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 1b5ac6b02bc5..ce6a42227249 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -670,6 +670,7 @@ properties:
       - items:
           - enum:
               - qcom,sa8295p-adp
+              - qcom,sa8540p-adp-ride
           - const: qcom,sa8540p
 
       - items:
-- 
2.17.1

[PATCH v5 2/3] arm64: dts: qcom: sa8295p: move common nodes to dtsi

[Parikshit Pareek]

There are many ADP boards with lot of common features. Move common
nodes, like remoteproc, regulators etc. to sa8540p-adp.dtsi file.
This will be base for many ADP boards to be introduced in near future.
Common nodes are like clocks, remoteproc, regulators etc.

The differences between the sa8295 ADP board, and sa8540p ADP board
(Qdrive-3), with respect to device/connector-interface, are as following:

PCIE: pcie nodes are not supported as of now, and will be supported
in subsequent patches.

UFS: Devices ufs_mem_hc and ufs_card_hc, both are mounted on ADP air
board. Whereas, only ufs_mem_hc is only mounted on Qdrive-3.

USB: Devices usb0 and usb2 are present on Qdrive-3 board. Whereas on sa8295
ADP board, usb0, usb1, and usb2 are present. On Qdrive-3, usb2 has only one
port supported(of the external embedded hub). Whereas on sa8295, all four
ports of usb2 are supported.

There are different connectors for ethernet and camera, but connected
to same interface towards soc. So, there is no need of any difference
regarding device tree.

Artificial intelligence chip SA9000P is present only on Qdrive-3 board
as PCIE endpoint.

Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts      | 528 +++++-------------
 .../{sa8295p-adp.dts => sa8540p-adp.dtsi}     | 133 -----
 2 files changed, 146 insertions(+), 515 deletions(-)
 rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%)
 copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
dissimilarity index 70%
index b608b82dff03..bf26fe5085bf 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -1,382 +1,146 @@
-// SPDX-License-Identifier: BSD-3-Clause
-/*
- * Copyright (c) 2021, The Linux Foundation. All rights reserved.
- * Copyright (c) 2022, Linaro Limited
- */
-
-/dts-v1/;
-
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
-#include <dt-bindings/spmi/spmi.h>
-
-#include "sa8540p.dtsi"
-
-/ {
-	model = "Qualcomm SA8295P ADP";
-	compatible = "qcom,sa8295p-adp", "qcom,sa8540p";
-
-	aliases {
-		serial0 = &qup2_uart17;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-};
-
-&apps_rsc {
-	pmm8540-a-regulators {
-		compatible = "qcom,pm8150-rpmh-regulators";
-		qcom,pmic-id = "a";
-
-		vreg_l3a: ldo3 {
-			regulator-name = "vreg_l3a";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1208000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l5a: ldo5 {
-			regulator-name = "vreg_l5a";
-			regulator-min-microvolt = <912000>;
-			regulator-max-microvolt = <912000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l7a: ldo7 {
-			regulator-name = "vreg_l7a";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l13a: ldo13 {
-			regulator-name = "vreg_l13a";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3072000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	pmm8540-c-regulators {
-		compatible = "qcom,pm8150-rpmh-regulators";
-		qcom,pmic-id = "c";
-
-		vreg_l1c: ldo1 {
-			regulator-name = "vreg_l1c";
-			regulator-min-microvolt = <912000>;
-			regulator-max-microvolt = <912000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2c: ldo2 {
-			regulator-name = "vreg_l2c";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3072000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3c: ldo3 {
-			regulator-name = "vreg_l3c";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-allow-set-load;
-		};
-
-		vreg_l4c: ldo4 {
-			regulator-name = "vreg_l4c";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1208000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l6c: ldo6 {
-			regulator-name = "vreg_l6c";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-allow-set-load;
-		};
-
-		vreg_l7c: ldo7 {
-			regulator-name = "vreg_l7c";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l10c: ldo10 {
-			regulator-name = "vreg_l10c";
-			regulator-min-microvolt = <2504000>;
-			regulator-max-microvolt = <2504000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-allow-set-load;
-		};
-
-		vreg_l17c: ldo17 {
-			regulator-name = "vreg_l17c";
-			regulator-min-microvolt = <2504000>;
-			regulator-max-microvolt = <2504000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-allow-set-load;
-		};
-	};
-
-	pmm8540-g-regulators {
-		compatible = "qcom,pm8150-rpmh-regulators";
-		qcom,pmic-id = "g";
-
-		vreg_l3g: ldo3 {
-			regulator-name = "vreg_l3g";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l7g: ldo7 {
-			regulator-name = "vreg_l7g";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l8g: ldo8 {
-			regulator-name = "vreg_l8g";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <880000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-};
-
-&qup2 {
-	status = "okay";
-};
-
-&qup2_uart17 {
-	compatible = "qcom,geni-debug-uart";
-	status = "okay";
-};
-
-&remoteproc_adsp {
-	firmware-name = "qcom/sa8540p/adsp.mbn";
-	status = "okay";
-};
-
-&remoteproc_nsp0 {
-	firmware-name = "qcom/sa8540p/cdsp.mbn";
-	status = "okay";
-};
-
-&remoteproc_nsp1 {
-	firmware-name = "qcom/sa8540p/cdsp1.mbn";
-	status = "okay";
-};
-
-&spmi_bus {
-	pm8450a: pmic@0 {
-		compatible = "qcom,pm8150", "qcom,spmi-pmic";
-		reg = <0x0 SPMI_USID>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pm8450a_gpios: gpio@c000 {
-			compatible = "qcom,pm8150-gpio", "qcom,spmi-gpio";
-			reg = <0xc000>;
-			gpio-controller;
-			gpio-ranges = <&pm8450a_gpios 0 0 10>;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-	};
-
-	pm8450c: pmic@4 {
-		compatible = "qcom,pm8150", "qcom,spmi-pmic";
-		reg = <0x4 SPMI_USID>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pm8450c_gpios: gpio@c000 {
-			compatible = "qcom,pm8150-gpio", "qcom,spmi-gpio";
-			reg = <0xc000>;
-			gpio-controller;
-			gpio-ranges = <&pm8450c_gpios 0 0 10>;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-	};
-
-	pm8450e: pmic@8 {
-		compatible = "qcom,pm8150", "qcom,spmi-pmic";
-		reg = <0x8 SPMI_USID>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pm8450e_gpios: gpio@c000 {
-			compatible = "qcom,pm8150-gpio", "qcom,spmi-gpio";
-			reg = <0xc000>;
-			gpio-controller;
-			gpio-ranges = <&pm8450e_gpios 0 0 10>;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-	};
-
-	pm8450g: pmic@c {
-		compatible = "qcom,pm8150", "qcom,spmi-pmic";
-		reg = <0xc SPMI_USID>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pm8450g_gpios: gpio@c000 {
-			compatible = "qcom,pm8150-gpio", "qcom,spmi-gpio";
-			reg = <0xc000>;
-			gpio-controller;
-			gpio-ranges = <&pm8450g_gpios 0 0 10>;
-			#gpio-cells = <2>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-	};
-};
-
-&ufs_mem_hc {
-	reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>;
-
-	vcc-supply = <&vreg_l17c>;
-	vcc-max-microamp = <800000>;
-	vccq-supply = <&vreg_l6c>;
-	vccq-max-microamp = <900000>;
-
-	status = "okay";
-};
-
-&ufs_mem_phy {
-	vdda-phy-supply = <&vreg_l8g>;
-	vdda-pll-supply = <&vreg_l3g>;
-
-	status = "okay";
-};
-
-&ufs_card_hc {
-	reset-gpios = <&tlmm 229 GPIO_ACTIVE_LOW>;
-
-	vcc-supply = <&vreg_l10c>;
-	vcc-max-microamp = <800000>;
-	vccq-supply = <&vreg_l3c>;
-	vccq-max-microamp = <900000>;
-
-	status = "okay";
-};
-
-&ufs_card_phy {
-	vdda-phy-supply = <&vreg_l8g>;
-	vdda-pll-supply = <&vreg_l3g>;
-
-	status = "okay";
-};
-
-&usb_0 {
-	status = "okay";
-};
-
-&usb_0_dwc3 {
-	/* TODO: Define USB-C connector properly */
-	dr_mode = "peripheral";
-};
-
-&usb_0_hsphy {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7a>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_0_qmpphy {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
-&usb_1 {
-	status = "okay";
-};
-
-&usb_1_dwc3 {
-	/* TODO: Define USB-C connector properly */
-	dr_mode = "host";
-};
-
-&usb_1_hsphy {
-	vdda-pll-supply = <&vreg_l1c>;
-	vdda18-supply = <&vreg_l7c>;
-	vdda33-supply = <&vreg_l2c>;
-
-	status = "okay";
-};
-
-&usb_1_qmpphy {
-	vdda-phy-supply = <&vreg_l4c>;
-	vdda-pll-supply = <&vreg_l1c>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy0 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy1 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy2 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy3 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_qmpphy0 {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
-&usb_2_qmpphy1 {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
-&xo_board_clk {
-	clock-frequency = <38400000>;
-};
-
-/* PINCTRL */
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+/dts-v1/;
+
+#include "sa8540p-adp.dtsi"
+
+/ {
+	model = "Qualcomm SA8295P ADP";
+	compatible = "qcom,sa8295p-adp", "qcom,sa8540p";
+};
+
+&ufs_mem_hc {
+	reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>;
+
+	vcc-supply = <&vreg_l17c>;
+	vcc-max-microamp = <800000>;
+	vccq-supply = <&vreg_l6c>;
+	vccq-max-microamp = <900000>;
+
+	status = "okay";
+};
+
+&ufs_mem_phy {
+	vdda-phy-supply = <&vreg_l8g>;
+	vdda-pll-supply = <&vreg_l3g>;
+
+	status = "okay";
+};
+
+&ufs_card_hc {
+	reset-gpios = <&tlmm 229 GPIO_ACTIVE_LOW>;
+
+	vcc-supply = <&vreg_l10c>;
+	vcc-max-microamp = <800000>;
+	vccq-supply = <&vreg_l3c>;
+	vccq-max-microamp = <900000>;
+
+	status = "okay";
+};
+
+&ufs_card_phy {
+	vdda-phy-supply = <&vreg_l8g>;
+	vdda-pll-supply = <&vreg_l3g>;
+
+	status = "okay";
+};
+
+&usb_0 {
+	status = "okay";
+};
+
+&usb_0_dwc3 {
+	/* TODO: Define USB-C connector properly */
+	dr_mode = "peripheral";
+};
+
+&usb_0_hsphy {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7a>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_0_qmpphy {
+	vdda-phy-supply = <&vreg_l3a>;
+	vdda-pll-supply = <&vreg_l5a>;
+
+	status = "okay";
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_1_dwc3 {
+	/* TODO: Define USB-C connector properly */
+	dr_mode = "host";
+};
+
+&usb_1_hsphy {
+	vdda-pll-supply = <&vreg_l1c>;
+	vdda18-supply = <&vreg_l7c>;
+	vdda33-supply = <&vreg_l2c>;
+
+	status = "okay";
+};
+
+&usb_1_qmpphy {
+	vdda-phy-supply = <&vreg_l4c>;
+	vdda-pll-supply = <&vreg_l1c>;
+
+	status = "okay";
+};
+
+&usb_2_hsphy0 {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7g>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_2_hsphy1 {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7g>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_2_hsphy2 {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7g>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_2_hsphy3 {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7g>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_2_qmpphy0 {
+	vdda-phy-supply = <&vreg_l3a>;
+	vdda-pll-supply = <&vreg_l5a>;
+
+	status = "okay";
+};
+
+&usb_2_qmpphy1 {
+	vdda-phy-supply = <&vreg_l3a>;
+	vdda-pll-supply = <&vreg_l5a>;
+
+	status = "okay";
+};
+
+/* PINCTRL */
diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8540p-adp.dtsi
similarity index 72%
copy from arch/arm64/boot/dts/qcom/sa8295p-adp.dts
copy to arch/arm64/boot/dts/qcom/sa8540p-adp.dtsi
index b608b82dff03..4c36bca2d72d 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8540p-adp.dtsi
@@ -13,9 +13,6 @@
 #include "sa8540p.dtsi"
 
 / {
-	model = "Qualcomm SA8295P ADP";
-	compatible = "qcom,sa8295p-adp", "qcom,sa8540p";
-
 	aliases {
 		serial0 = &qup2_uart17;
 	};
@@ -245,136 +242,6 @@
 	};
 };
 
-&ufs_mem_hc {
-	reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>;
-
-	vcc-supply = <&vreg_l17c>;
-	vcc-max-microamp = <800000>;
-	vccq-supply = <&vreg_l6c>;
-	vccq-max-microamp = <900000>;
-
-	status = "okay";
-};
-
-&ufs_mem_phy {
-	vdda-phy-supply = <&vreg_l8g>;
-	vdda-pll-supply = <&vreg_l3g>;
-
-	status = "okay";
-};
-
-&ufs_card_hc {
-	reset-gpios = <&tlmm 229 GPIO_ACTIVE_LOW>;
-
-	vcc-supply = <&vreg_l10c>;
-	vcc-max-microamp = <800000>;
-	vccq-supply = <&vreg_l3c>;
-	vccq-max-microamp = <900000>;
-
-	status = "okay";
-};
-
-&ufs_card_phy {
-	vdda-phy-supply = <&vreg_l8g>;
-	vdda-pll-supply = <&vreg_l3g>;
-
-	status = "okay";
-};
-
-&usb_0 {
-	status = "okay";
-};
-
-&usb_0_dwc3 {
-	/* TODO: Define USB-C connector properly */
-	dr_mode = "peripheral";
-};
-
-&usb_0_hsphy {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7a>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_0_qmpphy {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
-&usb_1 {
-	status = "okay";
-};
-
-&usb_1_dwc3 {
-	/* TODO: Define USB-C connector properly */
-	dr_mode = "host";
-};
-
-&usb_1_hsphy {
-	vdda-pll-supply = <&vreg_l1c>;
-	vdda18-supply = <&vreg_l7c>;
-	vdda33-supply = <&vreg_l2c>;
-
-	status = "okay";
-};
-
-&usb_1_qmpphy {
-	vdda-phy-supply = <&vreg_l4c>;
-	vdda-pll-supply = <&vreg_l1c>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy0 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy1 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy2 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_hsphy3 {
-	vdda-pll-supply = <&vreg_l5a>;
-	vdda18-supply = <&vreg_l7g>;
-	vdda33-supply = <&vreg_l13a>;
-
-	status = "okay";
-};
-
-&usb_2_qmpphy0 {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
-&usb_2_qmpphy1 {
-	vdda-phy-supply = <&vreg_l3a>;
-	vdda-pll-supply = <&vreg_l5a>;
-
-	status = "okay";
-};
-
 &xo_board_clk {
 	clock-frequency = <38400000>;
 };
-- 
2.17.1

[PATCH v5 3/3] arm64: dts: qcom: introduce sa8540p-ride dts

[Parikshit Pareek]

Create new dts file specific for Qdrive-3 board based on sa8540p chipset.
Introduce common dtsi file sa8295p-adp.dtsi, to be included for ADP and
Qdrive-3 board.

This is quite similar to sa8295 ADP development board. Main differences
are related to connectors, and interface cards, like USB external ports,
ethernet-switch, PCIe switch etc.

Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |  1 +
 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts | 72 +++++++++++++++++++
 2 files changed, 73 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index d7669a7cee9f..c68a9cac9b2b 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -54,6 +54,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qrb5165-rb5.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sa8155p-adp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sa8295p-adp.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sa8540p-adp-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-trogdor-coachz-r1.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-trogdor-coachz-r1-lte.dtb
diff --git a/arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts
new file mode 100644
index 000000000000..f5957bfea77b
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2022, Linaro Limited
+ * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "sa8540p-adp.dtsi"
+
+/ {
+	model = "Qualcomm SA8540 ADP";
+	compatible = "qcom,sa8540p-adp-ride", "qcom,sa8540p";
+};
+
+&ufs_mem_hc {
+	reset-gpios = <&tlmm 228 GPIO_ACTIVE_LOW>;
+
+	vcc-supply = <&vreg_l17c>;
+	vcc-max-microamp = <800000>;
+	vccq-supply = <&vreg_l6c>;
+	vccq-max-microamp = <900000>;
+
+	status = "okay";
+};
+
+&ufs_mem_phy {
+	vdda-phy-supply = <&vreg_l8g>;
+	vdda-pll-supply = <&vreg_l3g>;
+
+	status = "okay";
+};
+
+&usb_0 {
+	status = "okay";
+};
+
+&usb_0_dwc3 {
+	/* TODO: Define USB-C connector properly */
+	dr_mode = "peripheral";
+};
+
+&usb_0_hsphy {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7a>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_0_qmpphy {
+	vdda-phy-supply = <&vreg_l3a>;
+	vdda-pll-supply = <&vreg_l5a>;
+
+	status = "okay";
+};
+
+&usb_2_hsphy0 {
+	vdda-pll-supply = <&vreg_l5a>;
+	vdda18-supply = <&vreg_l7g>;
+	vdda33-supply = <&vreg_l13a>;
+
+	status = "okay";
+};
+
+&usb_2_qmpphy0 {
+	vdda-phy-supply = <&vreg_l3a>;
+	vdda-pll-supply = <&vreg_l5a>;
+
+	status = "okay";
+};
-- 
2.17.1

Re: [PATCH v5 2/3] arm64: dts: qcom: sa8295p: move common nodes to dtsi

[Krzysztof Kozlowski]

On 03/10/2022 14:54, Parikshit Pareek wrote:
> There are many ADP boards with lot of common features. Move common
> nodes, like remoteproc, regulators etc. to sa8540p-adp.dtsi file.
> This will be base for many ADP boards to be introduced in near future.
> Common nodes are like clocks, remoteproc, regulators etc.
> 
> The differences between the sa8295 ADP board, and sa8540p ADP board
> (Qdrive-3), with respect to device/connector-interface, are as following:
> 
> PCIE: pcie nodes are not supported as of now, and will be supported
> in subsequent patches.
> 
> UFS: Devices ufs_mem_hc and ufs_card_hc, both are mounted on ADP air
> board. Whereas, only ufs_mem_hc is only mounted on Qdrive-3.
> 
> USB: Devices usb0 and usb2 are present on Qdrive-3 board. Whereas on sa8295
> ADP board, usb0, usb1, and usb2 are present. On Qdrive-3, usb2 has only one
> port supported(of the external embedded hub). Whereas on sa8295, all four
> ports of usb2 are supported.
> 
> There are different connectors for ethernet and camera, but connected
> to same interface towards soc. So, there is no need of any difference
> regarding device tree.
> 
> Artificial intelligence chip SA9000P is present only on Qdrive-3 board
> as PCIE endpoint.
> 
> Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts      | 528 +++++-------------
>  .../{sa8295p-adp.dts => sa8540p-adp.dtsi}     | 133 -----
>  2 files changed, 146 insertions(+), 515 deletions(-)
>  rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%)
>  copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)
> 


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

Best regards,
Krzysztof

Re: [PATCH v5 3/3] arm64: dts: qcom: introduce sa8540p-ride dts

[Krzysztof Kozlowski]

On 03/10/2022 14:54, Parikshit Pareek wrote:
> Create new dts file specific for Qdrive-3 board based on sa8540p chipset.
> Introduce common dtsi file sa8295p-adp.dtsi, to be included for ADP and
> Qdrive-3 board.
> 
> This is quite similar to sa8295 ADP development board. Main differences
> are related to connectors, and interface cards, like USB external ports,
> ethernet-switch, PCIe switch etc.
> 
> Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
> ---


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

Best regards,
Krzysztof

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Brian Masney]

On Mon, Oct 03, 2022 at 06:24:40PM +0530, Parikshit Pareek wrote:
> Parikshit Pareek (3):
>   dt-bindings: arm: qcom: Document additional sa8540p device
>   arm64: dts: qcom: sa8295p: move common nodes to dtsi
>   arm64: dts: qcom: introduce sa8540p-ride dts

For the series:

Reviewed-by: Brian Masney <bmasney@redhat.com>
Tested-by: Brian Masney <bmasney@redhat.com>


Just for documentation purposes, to get linux-next-20220930 booting on
the QDrive3 with the upstream arm64 defconfig I had to apply the
following patches:

- arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size
  https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/

  Without this, the phy fails to probe due to the following error:

    qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507]
    qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16
    qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16

- This hack patch is still needed:
  disable has_address_auth_metacap and has_generic_auth
  https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5

  Without this, the boot hangs at:

    rcu: srcu_init: Setting srcu_struct sizes based on contention.
    arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
    clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
    sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns

- My UFS clock patch is still needed:
  arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy
  https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u

- I didn't use an initrd for testing so I had to change the options
  CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y.

Brian

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Andrew Halaney]

On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote:
> On Mon, Oct 03, 2022 at 06:24:40PM +0530, Parikshit Pareek wrote:
> > Parikshit Pareek (3):
> >   dt-bindings: arm: qcom: Document additional sa8540p device
> >   arm64: dts: qcom: sa8295p: move common nodes to dtsi
> >   arm64: dts: qcom: introduce sa8540p-ride dts
> 
> For the series:
> 
> Reviewed-by: Brian Masney <bmasney@redhat.com>
> Tested-by: Brian Masney <bmasney@redhat.com>

Tested-by: Andrew Halaney <ahalaney@redhat.com> # QDrive3/sa8540p-adp-ride
> 
> 
> Just for documentation purposes, to get linux-next-20220930 booting on
> the QDrive3 with the upstream arm64 defconfig I had to apply the
> following patches:
> 
> - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size
>   https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/
> 
>   Without this, the phy fails to probe due to the following error:
> 
>     qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507]
>     qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16
>     qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16
> 
> - This hack patch is still needed:
>   disable has_address_auth_metacap and has_generic_auth
>   https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5
> 
>   Without this, the boot hangs at:
> 
>     rcu: srcu_init: Setting srcu_struct sizes based on contention.
>     arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
>     clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
>     sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
> 
> - My UFS clock patch is still needed:
>   arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy
>   https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u
> 
> - I didn't use an initrd for testing so I had to change the options
>   CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y.
> 
> Brian
> 

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Konrad Dybcio]

On 03/10/2022 14:54, Parikshit Pareek wrote:
> Change in v5:
> - Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective
>    board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts.

Is there any benefit in this? USB0/2 and UFS (not UFS card) nodes are 
identical

in the 2 files.


Konrad

>    Took inputs from Shazad Hussain in this regard(John)
> - Added more description of the board differences(John)
> - Not including Reviewed-by for Krzysztof, because of the new changes to
>    be reviewed.
> - Removed Reported-by tag(John).
>
> Changes in v4:
>   - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board.
>   - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on
>     Qdrive3 board.
>   - Added Reported-by tag for Shazad(for ufs and usb_1 node removals)
>
> Changes in v3:
>   - Added Acked-by tag (Krzysztof)
>   - Renamed dtsi to sa8540p-adp.dtsi (John)
>   - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John)
>   - Added cover letter
>
> change in v2:
> - Make dt-binding patch as the first one in the patch set
> - Add , after year 2022, in the license header
>
> Initial version:
> - Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board
>    specific file sa8540p-adp-ride.dts.
>
>
> Parikshit Pareek (3):
>    dt-bindings: arm: qcom: Document additional sa8540p device
>    arm64: dts: qcom: sa8295p: move common nodes to dtsi
>    arm64: dts: qcom: introduce sa8540p-ride dts
>
>   .../devicetree/bindings/arm/qcom.yaml         |   1 +
>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>   arch/arm64/boot/dts/qcom/sa8295p-adp.dts      | 528 +++++-------------
>   arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts |  71 +++
>   .../{sa8295p-adp.dts => sa8540p-adp.dtsi}     | 133 -----
>   5 files changed, 219 insertions(+), 515 deletions(-)
>   rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%)
>   create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts
>   copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)
>

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Eric Chanudet]

On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote:
> Just for documentation purposes, to get linux-next-20220930 booting on
> the QDrive3 with the upstream arm64 defconfig I had to apply the
> following patches:
> 
> - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size
>   https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/
> 
>   Without this, the phy fails to probe due to the following error:
> 
>     qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507]
>     qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16
>     qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16
> 
> - This hack patch is still needed:
>   disable has_address_auth_metacap and has_generic_auth
>   https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5
> 
>   Without this, the boot hangs at:
> 
>     rcu: srcu_init: Setting srcu_struct sizes based on contention.
>     arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
>     clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
>     sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
> 
> - My UFS clock patch is still needed:
>   arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy
>   https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u
> 
> - I didn't use an initrd for testing so I had to change the options
>   CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y.
 
I followed the instructions above and linux-next-20220930 booted on the
QDrive3 to a prompt. It then hanged after a couple minutes and rebooted
in Sahara mode:
    B -   1662280 - Sahara Init
    B -   1665422 - Sahara Open

There seems to be no trace from the kernel, this happened consistently
over 3 boots.

I asked Brian, he mentioned he only booted to prompt so that may have
happened unbeknownst to him as well.

-- 
Eric Chanudet

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Andrew Halaney]

On Tue, Oct 04, 2022 at 09:28:16AM -0400, Eric Chanudet wrote:
> On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote:
> > Just for documentation purposes, to get linux-next-20220930 booting on
> > the QDrive3 with the upstream arm64 defconfig I had to apply the
> > following patches:
> > 
> > - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size
> >   https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/
> > 
> >   Without this, the phy fails to probe due to the following error:
> > 
> >     qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507]
> >     qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16
> >     qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16
> > 
> > - This hack patch is still needed:
> >   disable has_address_auth_metacap and has_generic_auth
> >   https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5
> > 
> >   Without this, the boot hangs at:
> > 
> >     rcu: srcu_init: Setting srcu_struct sizes based on contention.
> >     arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
> >     clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
> >     sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
> > 
> > - My UFS clock patch is still needed:
> >   arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy
> >   https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u
> > 
> > - I didn't use an initrd for testing so I had to change the options
> >   CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y.
>  
> I followed the instructions above and linux-next-20220930 booted on the
> QDrive3 to a prompt. It then hanged after a couple minutes and rebooted
> in Sahara mode:
>     B -   1662280 - Sahara Init
>     B -   1665422 - Sahara Open
> 
> There seems to be no trace from the kernel, this happened consistently
> over 3 boots.
> 
> I asked Brian, he mentioned he only booted to prompt so that may have
> happened unbeknownst to him as well.

I took the upstream defconfig for a spin and see similar. My T-B was for
this defconfig (downstream one + make olddefconfig) which works ok for
me:

    https://gitlab.com/ahalaney/linux/-/commit/40f1b241117716ef4b0e27cf50054e749b8ff608

Thanks,
Andrew

> 
> -- 
> Eric Chanudet
> 

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Parikshit Pareek]

On Mon, Oct 03, 2022 at 11:05:11PM +0200, Konrad Dybcio wrote:
> 
> On 03/10/2022 14:54, Parikshit Pareek wrote:
> > Change in v5:
> > - Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective
> >    board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts.
> 
> Is there any benefit in this? USB0/2 and UFS (not UFS card) nodes are
> identical
> 
> in the 2 files.
Similar boards might come in future, anticipated to be differing mainly
with respect to usb/ufs. Hence thought it better to put ufs/usb nodes in
board specific dts.

Regards,
Parikshit Pareek
> 
> 
> Konrad
> 
> >    Took inputs from Shazad Hussain in this regard(John)
> > - Added more description of the board differences(John)
> > - Not including Reviewed-by for Krzysztof, because of the new changes to
> >    be reviewed.
> > - Removed Reported-by tag(John).
> > 
> > Changes in v4:
> >   - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board.
> >   - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on
> >     Qdrive3 board.
> >   - Added Reported-by tag for Shazad(for ufs and usb_1 node removals)
> > 
> > Changes in v3:
> >   - Added Acked-by tag (Krzysztof)
> >   - Renamed dtsi to sa8540p-adp.dtsi (John)
> >   - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John)
> >   - Added cover letter
> > 
> > change in v2:
> > - Make dt-binding patch as the first one in the patch set
> > - Add , after year 2022, in the license header
> > 
> > Initial version:
> > - Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board
> >    specific file sa8540p-adp-ride.dts.
> > 
> > 
> > Parikshit Pareek (3):
> >    dt-bindings: arm: qcom: Document additional sa8540p device
> >    arm64: dts: qcom: sa8295p: move common nodes to dtsi
> >    arm64: dts: qcom: introduce sa8540p-ride dts
> > 
> >   .../devicetree/bindings/arm/qcom.yaml         |   1 +
> >   arch/arm64/boot/dts/qcom/Makefile             |   1 +
> >   arch/arm64/boot/dts/qcom/sa8295p-adp.dts      | 528 +++++-------------
> >   arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts |  71 +++
> >   .../{sa8295p-adp.dts => sa8540p-adp.dtsi}     | 133 -----
> >   5 files changed, 219 insertions(+), 515 deletions(-)
> >   rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%)
> >   create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts
> >   copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)
> > 

Re: [PATCH v5 2/3] arm64: dts: qcom: sa8295p: move common nodes to dtsi

[Bjorn Andersson]

On Mon, Oct 03, 2022 at 06:24:43PM +0530, Parikshit Pareek wrote:
> There are many ADP boards with lot of common features. Move common
> nodes, like remoteproc, regulators etc. to sa8540p-adp.dtsi file.
> This will be base for many ADP boards to be introduced in near future.
> Common nodes are like clocks, remoteproc, regulators etc.
> 
> The differences between the sa8295 ADP board, and sa8540p ADP board
> (Qdrive-3), with respect to device/connector-interface, are as following:
> 

After reviewing the qdrive3 schematics I do think that describing the
two ADP boards as a delta between them is not going to serve us well in
the long run - they are quite different.

So let's just create a new dts for the qdrive3, and if there are
additional boards they will either again be sufficiently different or we
could turn these into dtsi files and inherit from there.

Regards,
Bjorn

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Brian Masney]

On Tue, Oct 04, 2022 at 09:28:16AM -0400, Eric Chanudet wrote:
> I followed the instructions above and linux-next-20220930 booted on the
> QDrive3 to a prompt. It then hanged after a couple minutes and rebooted
> in Sahara mode:
>     B -   1662280 - Sahara Init
>     B -   1665422 - Sahara Open
> 
> There seems to be no trace from the kernel, this happened consistently
> over 3 boots.
> 
> I asked Brian, he mentioned he only booted to prompt so that may have
> happened unbeknownst to him as well.

Good catch, Eric!

Parikshit: I found a way to reproduce the crash and isolated the issue
to the qcom_q6v5_pas driver. Here's how you can reproduce the crash
that we're seeing:

1) Use my instructions at [1] to build an upstream kernel with the arm64
   defconfg. Today I used linux-next-20221017.

2) Copy the modules to the root filesystem. Before you reboot, mv
   /lib/modules/6.0.0-next-20221017-xxx to
   /lib/modules/6.0.0-next-20221017-xxx-old so that the modules are not
   automatically loaded on startup.

3) Reboot, and run lsmod and verify that no modules are loaded.

4) cd /lib/modules/6.0.0-next-20221017-xxx-old

5) Now load the modules that work as expected that are loaded with the
   upstream arm64 defconfig:

        insmod ./kernel/net/rfkill/rfkill.ko
        insmod ./kernel/arch/arm64/crypto/crct10dif-ce.ko
        insmod ./kernel/net/qrtr/qrtr.ko
        insmod ./kernel/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.ko
        insmod ./kernel/drivers/soc/qcom/llcc-qcom.ko
        insmod ./kernel/drivers/soc/qcom/qmi_helpers.ko
        insmod ./kernel/drivers/remoteproc/qcom_sysmon.ko
        insmod ./kernel/drivers/remoteproc/qcom_q6v5.ko
        insmod ./kernel/drivers/rpmsg/qcom_glink_smem.ko
        insmod ./kernel/drivers/soc/qcom/socinfo.ko
        insmod ./kernel/drivers/remoteproc/qcom_pil_info.ko
        insmod ./kernel/drivers/remoteproc/qcom_common.ko
        insmod ./kernel/drivers/watchdog/qcom-wdt.ko
        insmod ./kernel/fs/fuse/fuse.ko
        insmod ./kernel/drivers/soc/qcom/mdt_loader.ko

6) Wait a few minutes to be sure that everything is working as expected
   on the board.

7) Make the board go BOOM:

        insmod ./kernel/drivers/remoteproc/qcom_q6v5_pas.ko

We don't know how or have the tools to analyze the ramdumps from the
Qualcomm firmware at Red Hat, so we're flying blind right now.

[1] https://lore.kernel.org/lkml/YzsciFeYpvv%2F92CG@x1/

Brian

Re: [PATCH v5 0/3] arm64: dts: qcom: add dts for sa8540p-ride board

[Brian Masney]

On Mon, Oct 17, 2022 at 03:23:25PM -0400, Brian Masney wrote:
> Parikshit: I found a way to reproduce the crash and isolated the issue
> to the qcom_q6v5_pas driver. Here's how you can reproduce the crash
> that we're seeing:
> 
> 1) Use my instructions at [1] to build an upstream kernel with the arm64
>    defconfg. Today I used linux-next-20221017.
> 
> 2) Copy the modules to the root filesystem. Before you reboot, mv
>    /lib/modules/6.0.0-next-20221017-xxx to
>    /lib/modules/6.0.0-next-20221017-xxx-old so that the modules are not
>    automatically loaded on startup.
> 
> 3) Reboot, and run lsmod and verify that no modules are loaded.
> 
> 4) cd /lib/modules/6.0.0-next-20221017-xxx-old
> 
> 5) Now load the modules that work as expected that are loaded with the
>    upstream arm64 defconfig:
> 
>         insmod ./kernel/net/rfkill/rfkill.ko
>         insmod ./kernel/arch/arm64/crypto/crct10dif-ce.ko
>         insmod ./kernel/net/qrtr/qrtr.ko
>         insmod ./kernel/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.ko
>         insmod ./kernel/drivers/soc/qcom/llcc-qcom.ko
>         insmod ./kernel/drivers/soc/qcom/qmi_helpers.ko
>         insmod ./kernel/drivers/remoteproc/qcom_sysmon.ko
>         insmod ./kernel/drivers/remoteproc/qcom_q6v5.ko
>         insmod ./kernel/drivers/rpmsg/qcom_glink_smem.ko
>         insmod ./kernel/drivers/soc/qcom/socinfo.ko
>         insmod ./kernel/drivers/remoteproc/qcom_pil_info.ko
>         insmod ./kernel/drivers/remoteproc/qcom_common.ko
>         insmod ./kernel/drivers/watchdog/qcom-wdt.ko
>         insmod ./kernel/fs/fuse/fuse.ko
>         insmod ./kernel/drivers/soc/qcom/mdt_loader.ko
> 
> 6) Wait a few minutes to be sure that everything is working as expected
>    on the board.
> 
> 7) Make the board go BOOM:
> 
>         insmod ./kernel/drivers/remoteproc/qcom_q6v5_pas.ko
> 
> We don't know how or have the tools to analyze the ramdumps from the
> Qualcomm firmware at Red Hat, so we're flying blind right now.
> 
> [1] https://lore.kernel.org/lkml/YzsciFeYpvv%2F92CG@x1/

I isolated the hang issue above to a single Kconfig symbol. First, a
quick background. We're not seeing the hang issue using the upstream
kernel with Red Hat's automotive kernel config. We see the hang though
with the upstream arm64 defconfig. There's thousands of symbol
differences between the two defconfigs and none of the changes stuck out
to me. I wrote some code that slowly morphed the Red Hat defconfig into
the upstream arm64 defconfig and committed the symbol changes in stages
along the way. This allowed me to do an automated 'git bisect'.

The symbol CONFIG_NO_HZ_IDLE=y is what triggers the hang. When I remove
that line from arch/arm64/configs/defconfig, then the board continues to
function normally after the qcom_q6v5_pas.ko module is loaded.

Any ideas what could be causing this? Could it be the safety island is
monitoring for a kernel tick and if it doesn't sense one then it kills
the kernel and goes into ramdump mode?

Brian