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
Add the ADP ride device to the valid device compatibles found on the
sa8540p platform.
Signed-off-by: Parikshit Pareek <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
Tested-by: Brian Masney <[email protected]>
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/[email protected]/
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/[email protected]/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
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 <[email protected]>
> Tested-by: Brian Masney <[email protected]>
Tested-by: Andrew Halaney <[email protected]> # 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/[email protected]/
>
> 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/[email protected]/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
>
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%)
>
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/[email protected]/
>
> 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/[email protected]/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
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/[email protected]/
> >
> > 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/[email protected]/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
>
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%)
> >
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
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
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