* [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes
@ 2022-12-12 18:23 Brian Masney
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
` (3 more replies)
0 siblings, 4 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-12 18:23 UTC (permalink / raw)
To: andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
This patch series adds the i2c and spi nodes that are missing on the
sc8280xp platform.
Note that this series needs to be applied on top of:
[PATCH v3] arm64: dts: qcom: sa8540p-ride: enable pcie2a node
https://lore.kernel.org/lkml/20221212150045.4252-1-quic_shazhuss@quicinc.com/
Brian Masney (4):
arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
arm64: dts: qcom: sc8280xp: add missing i2c nodes
arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
arm64: dts: qcom: sc8280xp: add missing spi nodes
arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 46 ++
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 6 +-
.../qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +-
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 738 +++++++++++++++++-
4 files changed, 789 insertions(+), 7 deletions(-)
--
2.38.1
^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-12 18:23 [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes Brian Masney
@ 2022-12-12 18:23 ` Brian Masney
2022-12-12 18:48 ` Konrad Dybcio
2022-12-13 14:54 ` Johan Hovold
2022-12-12 18:23 ` [PATCH 2/4] arm64: dts: qcom: sc8280xp: add missing i2c nodes Brian Masney
` (2 subsequent siblings)
3 siblings, 2 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-12 18:23 UTC (permalink / raw)
To: andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
According to the downstream 5.4 kernel sources for the sa8540p,
i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
also match. Let's go ahead and correct the name that's used in the
three files where this is listed.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
---
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 6 +++---
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +++---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index 551768f97729..1ab76724144d 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -326,11 +326,11 @@ &qup2 {
status = "okay";
};
-&qup2_i2c5 {
+&qup2_i2c21 {
clock-frequency = <400000>;
pinctrl-names = "default";
- pinctrl-0 = <&qup2_i2c5_default>;
+ pinctrl-0 = <&qup2_i2c21_default>;
status = "okay";
@@ -598,7 +598,7 @@ qup0_i2c4_default: qup0-i2c4-default-state {
drive-strength = <16>;
};
- qup2_i2c5_default: qup2-i2c5-default-state {
+ qup2_i2c21_default: qup2-i2c21-default-state {
pins = "gpio81", "gpio82";
function = "qup21";
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 568c6be1ceaa..284adf60386a 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -531,11 +531,11 @@ &qup2 {
status = "okay";
};
-&qup2_i2c5 {
+&qup2_i2c21 {
clock-frequency = <400000>;
pinctrl-names = "default";
- pinctrl-0 = <&qup2_i2c5_default>;
+ pinctrl-0 = <&qup2_i2c21_default>;
status = "okay";
@@ -801,7 +801,7 @@ qup0_i2c4_default: qup0-i2c4-default-state {
drive-strength = <16>;
};
- qup2_i2c5_default: qup2-i2c5-default-state {
+ qup2_i2c21_default: qup2-i2c21-default-state {
pins = "gpio81", "gpio82";
function = "qup21";
bias-disable;
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 109c9d2b684d..875cc91324ce 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
status = "disabled";
};
- qup2_i2c5: i2c@894000 {
+ qup2_i2c21: i2c@894000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00894000 0 0x4000>;
clock-names = "se";
--
2.38.1
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 2/4] arm64: dts: qcom: sc8280xp: add missing i2c nodes
2022-12-12 18:23 [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes Brian Masney
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
@ 2022-12-12 18:23 ` Brian Masney
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
2022-12-12 18:23 ` [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes Brian Masney
3 siblings, 0 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-12 18:23 UTC (permalink / raw)
To: andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
Add the missing nodes for the i2c buses that's present on this SoC.
This work was derived from various patches that Qualcomm delivered
to Red Hat in a downstream kernel.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 352 +++++++++++++++++++++++++
1 file changed, 352 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 875cc91324ce..392a1509f0be 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -813,6 +813,38 @@ qup2: geniqup@8c0000 {
status = "disabled";
+ qup2_i2c16: i2c@880000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00880000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup2_i2c17: i2c@884000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00884000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S1_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 583 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
qup2_uart17: serial@884000 {
compatible = "qcom,geni-uart";
reg = <0 0x00884000 0 0x4000>;
@@ -827,6 +859,54 @@ qup2_uart17: serial@884000 {
status = "disabled";
};
+ qup2_i2c18: i2c@888000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00888000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S2_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 584 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup2_i2c19: i2c@88c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x0088c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S3_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 585 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup2_i2c20: i2c@890000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00890000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S4_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
qup2_i2c21: i2c@894000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00894000 0 0x4000>;
@@ -842,6 +922,38 @@ qup2_i2c21: i2c@894000 {
interconnect-names = "qup-core", "qup-config", "qup-memory";
status = "disabled";
};
+
+ qup2_i2c22: i2c@898000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00898000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP2_S6_CLK>;
+ interrupts = <GIC_SPI 833 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup2_i2c23: i2c@89c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x0089c000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP2_S7_CLK>;
+ interrupts = <GIC_SPI 834 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
};
qup0: geniqup@9c0000 {
@@ -858,6 +970,70 @@ qup0: geniqup@9c0000 {
status = "disabled";
+ qup0_i2c0: i2c@980000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00980000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup0_i2c1: i2c@984000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00984000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup0_i2c2: i2c@988000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00988000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup0_i2c3: i2c@98c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x0098c000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
qup0_i2c4: i2c@990000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00990000 0 0x4000>;
@@ -873,6 +1049,54 @@ qup0_i2c4: i2c@990000 {
interconnect-names = "qup-core", "qup-config", "qup-memory";
status = "disabled";
};
+
+ qup0_i2c5: i2c@994000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00994000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup0_i2c6: i2c@998000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00998000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup0_i2c7: i2c@99c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x0099c000 0 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
};
qup1: geniqup@ac0000 {
@@ -888,6 +1112,134 @@ qup1: geniqup@ac0000 {
ranges;
status = "disabled";
+
+ qup1_i2c8: i2c@a80000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a80000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c9: i2c@a84000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a84000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c10: i2c@a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a88000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c11: i2c@a8c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a8c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c12: i2c@a90000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a90000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c13: i2c@a94000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a94000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c14: i2c@a98000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a98000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 835 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
+
+ qup1_i2c15: i2c@a9c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0 0x00a9c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ status = "disabled";
+ };
};
pcie4: pcie@1c00000 {
--
2.38.1
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-12 18:23 [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes Brian Masney
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
2022-12-12 18:23 ` [PATCH 2/4] arm64: dts: qcom: sc8280xp: add missing i2c nodes Brian Masney
@ 2022-12-12 18:23 ` Brian Masney
2022-12-13 7:18 ` Shazad Hussain
` (3 more replies)
2022-12-12 18:23 ` [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes Brian Masney
3 siblings, 4 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-12 18:23 UTC (permalink / raw)
To: andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
Add the necessary nodes in order to get qup1_i2c15 and qup2_i2c18
functioning on the automotive board and exposed to userspace.
This work was derived from various patches that Qualcomm delivered
to Red Hat in a downstream kernel. This change was validated by using
i2c-tools 4.3.3 on CentOS Stream 9:
[root@localhost ~]# i2cdetect -l
i2c-15 i2c Geni-I2C I2C adapter
i2c-18 i2c Geni-I2C I2C adapter
[root@localhost ~]# i2cdetect -a -y 15
Warning: Can't use SMBus Quick Write command, will skip some addresses
0 1 2 3 4 5 6 7 8 9 a b c d e f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:
Bus 18 has the same output. I validated that we get the same output on
the downstream kernel.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 46 +++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
index d70859803fbd..6dc3f3ff8ece 100644
--- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
@@ -17,6 +17,8 @@ / {
compatible = "qcom,sa8540p-ride", "qcom,sa8540p";
aliases {
+ i2c15 = &qup1_i2c15;
+ i2c18 = &qup2_i2c18;
serial0 = &qup2_uart17;
};
@@ -188,10 +190,28 @@ &pcie3a_phy {
status = "okay";
};
+&qup1 {
+ status = "okay";
+};
+
+&qup1_i2c15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup1_i2c15_default>;
+
+ status = "okay";
+};
+
&qup2 {
status = "okay";
};
+&qup2_i2c18 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup2_i2c18_default>;
+
+ status = "okay";
+};
+
&qup2_uart17 {
compatible = "qcom,geni-debug-uart";
status = "okay";
@@ -313,4 +333,30 @@ wake-pins {
bias-pull-up;
};
};
+
+ qup1_i2c15_default: qup1-i2c15-state {
+ mux-pins {
+ pins = "gpio36", "gpio37";
+ function = "qup15";
+ };
+
+ config-pins {
+ pins = "gpio36", "gpio37";
+ drive-strength = <0x02>;
+ bias-pull-up;
+ };
+ };
+
+ qup2_i2c18_default: qup2-i2c18-state {
+ mux-pins {
+ pins = "gpio66", "gpio67";
+ function = "qup18";
+ };
+
+ config-pins {
+ pins = "gpio66", "gpio67";
+ drive-strength = <0x02>;
+ bias-pull-up;
+ };
+ };
};
--
2.38.1
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-12 18:23 [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes Brian Masney
` (2 preceding siblings ...)
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
@ 2022-12-12 18:23 ` Brian Masney
2022-12-13 7:16 ` Shazad Hussain
3 siblings, 1 reply; 40+ messages in thread
From: Brian Masney @ 2022-12-12 18:23 UTC (permalink / raw)
To: andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
Add the missing nodes for the spi buses that's present on this SoC.
This work was derived from various patches that Qualcomm delivered
to Red Hat in a downstream kernel.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
1 file changed, 384 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 392a1509f0be..b50db09feae2 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -829,6 +829,22 @@ qup2_i2c16: i2c@880000 {
status = "disabled";
};
+ qup2_spi16: spi@880000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00880000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c17: i2c@884000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00884000 0 0x4000>;
@@ -845,6 +861,22 @@ qup2_i2c17: i2c@884000 {
status = "disabled";
};
+ qup2_spi17: spi@884000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00884000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S1_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 583 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_uart17: serial@884000 {
compatible = "qcom,geni-uart";
reg = <0 0x00884000 0 0x4000>;
@@ -875,6 +907,22 @@ qup2_i2c18: i2c@888000 {
status = "disabled";
};
+ qup2_spi18: spi@888000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00888000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S2_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 584 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c19: i2c@88c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x0088c000 0 0x4000>;
@@ -891,6 +939,22 @@ qup2_i2c19: i2c@88c000 {
status = "disabled";
};
+ qup2_spi19: spi@88c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x0088c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S3_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 585 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c20: i2c@890000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00890000 0 0x4000>;
@@ -907,6 +971,22 @@ qup2_i2c20: i2c@890000 {
status = "disabled";
};
+ qup2_spi20: spi@890000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00890000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S4_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c21: i2c@894000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00894000 0 0x4000>;
@@ -923,6 +1003,22 @@ qup2_i2c21: i2c@894000 {
status = "disabled";
};
+ qup2_spi21: spi@894000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00894000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S5_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 587 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c22: i2c@898000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00898000 0 0x4000>;
@@ -939,6 +1035,22 @@ qup2_i2c22: i2c@898000 {
status = "disabled";
};
+ qup2_spi22: spi@898000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00898000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S6_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 833 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup2_i2c23: i2c@89c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x0089c000 0 0x4000>;
@@ -954,6 +1066,22 @@ qup2_i2c23: i2c@89c000 {
interconnect-names = "qup-core", "qup-config", "qup-memory";
status = "disabled";
};
+
+ qup2_spi23: spi@89c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x0089c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S7_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 834 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
+ <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
};
qup0: geniqup@9c0000 {
@@ -986,6 +1114,22 @@ qup0_i2c0: i2c@980000 {
status = "disabled";
};
+ qup0_spi0: spi@980000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00980000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c1: i2c@984000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00984000 0 0x4000>;
@@ -1002,6 +1146,22 @@ qup0_i2c1: i2c@984000 {
status = "disabled";
};
+ qup0_spi1: spi@984000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00984000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S1_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c2: i2c@988000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00988000 0 0x4000>;
@@ -1018,6 +1178,22 @@ qup0_i2c2: i2c@988000 {
status = "disabled";
};
+ qup0_spi2: spi@988000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00988000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S2_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c3: i2c@98c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x0098c000 0 0x4000>;
@@ -1034,6 +1210,22 @@ qup0_i2c3: i2c@98c000 {
status = "disabled";
};
+ qup0_spi3: spi@98c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x0098c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S3_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c4: i2c@990000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00990000 0 0x4000>;
@@ -1050,6 +1242,22 @@ qup0_i2c4: i2c@990000 {
status = "disabled";
};
+ qup0_spi4: spi@990000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00990000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S4_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c5: i2c@994000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00994000 0 0x4000>;
@@ -1066,6 +1274,22 @@ qup0_i2c5: i2c@994000 {
status = "disabled";
};
+ qup0_spi5: spi@994000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00994000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S5_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c6: i2c@998000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00998000 0 0x4000>;
@@ -1082,6 +1306,22 @@ qup0_i2c6: i2c@998000 {
status = "disabled";
};
+ qup0_spi6: spi@998000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00998000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S6_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup0_i2c7: i2c@99c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x0099c000 0 0x4000>;
@@ -1097,6 +1337,22 @@ qup0_i2c7: i2c@99c000 {
interconnect-names = "qup-core", "qup-config", "qup-memory";
status = "disabled";
};
+
+ qup0_spi7: spi@99c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x0099c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP2_S7_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
+ <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
};
qup1: geniqup@ac0000 {
@@ -1129,6 +1385,22 @@ qup1_i2c8: i2c@a80000 {
status = "disabled";
};
+ qup1_spi8: spi@a80000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a80000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c9: i2c@a84000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a84000 0 0x4000>;
@@ -1145,6 +1417,22 @@ qup1_i2c9: i2c@a84000 {
status = "disabled";
};
+ qup1_spi9: spi@a84000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a84000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c10: i2c@a88000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a88000 0 0x4000>;
@@ -1161,6 +1449,22 @@ qup1_i2c10: i2c@a88000 {
status = "disabled";
};
+ qup1_spi10: spi@a88000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a88000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c11: i2c@a8c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a8c000 0 0x4000>;
@@ -1177,6 +1481,22 @@ qup1_i2c11: i2c@a8c000 {
status = "disabled";
};
+ qup1_spi11: spi@a8c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a8c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c12: i2c@a90000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a90000 0 0x4000>;
@@ -1193,6 +1513,22 @@ qup1_i2c12: i2c@a90000 {
status = "disabled";
};
+ qup1_spi12: spi@a90000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a90000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c13: i2c@a94000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a94000 0 0x4000>;
@@ -1209,6 +1545,22 @@ qup1_i2c13: i2c@a94000 {
status = "disabled";
};
+ qup1_spi13: spi@a94000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a94000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c14: i2c@a98000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a98000 0 0x4000>;
@@ -1225,6 +1577,22 @@ qup1_i2c14: i2c@a98000 {
status = "disabled";
};
+ qup1_spi14: spi@a98000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a98000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 835 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
+
qup1_i2c15: i2c@a9c000 {
compatible = "qcom,geni-i2c";
reg = <0 0x00a9c000 0 0x4000>;
@@ -1240,6 +1608,22 @@ qup1_i2c15: i2c@a9c000 {
interconnect-names = "qup-core", "qup-config", "qup-memory";
status = "disabled";
};
+
+ qup1_spi15: spi@a9c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0 0x00a9c000 0 0x4000>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ clock-names = "se";
+ interrupts = <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
+ <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "qup-core", "qup-config", "qup-memory";
+ spi-max-frequency = <50000000>;
+ status = "disabled";
+ };
};
pcie4: pcie@1c00000 {
--
2.38.1
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
@ 2022-12-12 18:48 ` Konrad Dybcio
2022-12-13 14:54 ` Johan Hovold
1 sibling, 0 replies; 40+ messages in thread
From: Konrad Dybcio @ 2022-12-12 18:48 UTC (permalink / raw)
To: Brian Masney, andersson, krzysztof.kozlowski+dt
Cc: robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude, quic_shazhuss
On 12.12.2022 19:23, Brian Masney wrote:
> According to the downstream 5.4 kernel sources for the sa8540p,
> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
> also match. Let's go ahead and correct the name that's used in the
> three files where this is listed.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
> arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 6 +++---
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +++---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> index 551768f97729..1ab76724144d 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> @@ -326,11 +326,11 @@ &qup2 {
> status = "okay";
> };
>
> -&qup2_i2c5 {
> +&qup2_i2c21 {
> clock-frequency = <400000>;
>
> pinctrl-names = "default";
> - pinctrl-0 = <&qup2_i2c5_default>;
> + pinctrl-0 = <&qup2_i2c21_default>;
>
> status = "okay";
>
> @@ -598,7 +598,7 @@ qup0_i2c4_default: qup0-i2c4-default-state {
> drive-strength = <16>;
> };
>
> - qup2_i2c5_default: qup2-i2c5-default-state {
> + qup2_i2c21_default: qup2-i2c21-default-state {
> pins = "gpio81", "gpio82";
> function = "qup21";
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index 568c6be1ceaa..284adf60386a 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -531,11 +531,11 @@ &qup2 {
> status = "okay";
> };
>
> -&qup2_i2c5 {
> +&qup2_i2c21 {
> clock-frequency = <400000>;
>
> pinctrl-names = "default";
> - pinctrl-0 = <&qup2_i2c5_default>;
> + pinctrl-0 = <&qup2_i2c21_default>;
>
> status = "okay";
>
> @@ -801,7 +801,7 @@ qup0_i2c4_default: qup0-i2c4-default-state {
> drive-strength = <16>;
> };
>
> - qup2_i2c5_default: qup2-i2c5-default-state {
> + qup2_i2c21_default: qup2-i2c21-default-state {
> pins = "gpio81", "gpio82";
> function = "qup21";
> bias-disable;
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 109c9d2b684d..875cc91324ce 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
> status = "disabled";
> };
>
> - qup2_i2c5: i2c@894000 {
> + qup2_i2c21: i2c@894000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00894000 0 0x4000>;
> clock-names = "se";
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-12 18:23 ` [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes Brian Masney
@ 2022-12-13 7:16 ` Shazad Hussain
2022-12-13 12:27 ` Brian Masney
0 siblings, 1 reply; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 7:16 UTC (permalink / raw)
To: Brian Masney, andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude
On 12/12/2022 11:53 PM, Brian Masney wrote:
> Add the missing nodes for the spi buses that's present on this SoC.
>
> This work was derived from various patches that Qualcomm delivered
> to Red Hat in a downstream kernel.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
> 1 file changed, 384 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 392a1509f0be..b50db09feae2 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -829,6 +829,22 @@ qup2_i2c16: i2c@880000 {
> status = "disabled";
> };
>
> + qup2_spi16: spi@880000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00880000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
This is device property not host and same applicable for all below spi
nodes.
Also FYI let's enable below SPI for Qdrive usecases once spidev
compatible name is confirmed.
SE9 0x00A84000
SE22 0x00898000
-Shazad
> + status = "disabled";
> + };
> +
> qup2_i2c17: i2c@884000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00884000 0 0x4000>;
> @@ -845,6 +861,22 @@ qup2_i2c17: i2c@884000 {
> status = "disabled";
> };
>
> + qup2_spi17: spi@884000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00884000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S1_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 583 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_uart17: serial@884000 {
> compatible = "qcom,geni-uart";
> reg = <0 0x00884000 0 0x4000>;
> @@ -875,6 +907,22 @@ qup2_i2c18: i2c@888000 {
> status = "disabled";
> };
>
> + qup2_spi18: spi@888000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00888000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S2_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 584 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_i2c19: i2c@88c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x0088c000 0 0x4000>;
> @@ -891,6 +939,22 @@ qup2_i2c19: i2c@88c000 {
> status = "disabled";
> };
>
> + qup2_spi19: spi@88c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x0088c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S3_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 585 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_i2c20: i2c@890000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00890000 0 0x4000>;
> @@ -907,6 +971,22 @@ qup2_i2c20: i2c@890000 {
> status = "disabled";
> };
>
> + qup2_spi20: spi@890000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00890000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S4_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_i2c21: i2c@894000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00894000 0 0x4000>;
> @@ -923,6 +1003,22 @@ qup2_i2c21: i2c@894000 {
> status = "disabled";
> };
>
> + qup2_spi21: spi@894000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00894000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S5_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 587 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_i2c22: i2c@898000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00898000 0 0x4000>;
> @@ -939,6 +1035,22 @@ qup2_i2c22: i2c@898000 {
> status = "disabled";
> };
>
> + qup2_spi22: spi@898000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00898000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S6_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 833 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup2_i2c23: i2c@89c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x0089c000 0 0x4000>;
> @@ -954,6 +1066,22 @@ qup2_i2c23: i2c@89c000 {
> interconnect-names = "qup-core", "qup-config", "qup-memory";
> status = "disabled";
> };
> +
> + qup2_spi23: spi@89c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x0089c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S7_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 834 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> };
>
> qup0: geniqup@9c0000 {
> @@ -986,6 +1114,22 @@ qup0_i2c0: i2c@980000 {
> status = "disabled";
> };
>
> + qup0_spi0: spi@980000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00980000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c1: i2c@984000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00984000 0 0x4000>;
> @@ -1002,6 +1146,22 @@ qup0_i2c1: i2c@984000 {
> status = "disabled";
> };
>
> + qup0_spi1: spi@984000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00984000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S1_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c2: i2c@988000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00988000 0 0x4000>;
> @@ -1018,6 +1178,22 @@ qup0_i2c2: i2c@988000 {
> status = "disabled";
> };
>
> + qup0_spi2: spi@988000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00988000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S2_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c3: i2c@98c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x0098c000 0 0x4000>;
> @@ -1034,6 +1210,22 @@ qup0_i2c3: i2c@98c000 {
> status = "disabled";
> };
>
> + qup0_spi3: spi@98c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x0098c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S3_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c4: i2c@990000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00990000 0 0x4000>;
> @@ -1050,6 +1242,22 @@ qup0_i2c4: i2c@990000 {
> status = "disabled";
> };
>
> + qup0_spi4: spi@990000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00990000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S4_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c5: i2c@994000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00994000 0 0x4000>;
> @@ -1066,6 +1274,22 @@ qup0_i2c5: i2c@994000 {
> status = "disabled";
> };
>
> + qup0_spi5: spi@994000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00994000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S5_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c6: i2c@998000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00998000 0 0x4000>;
> @@ -1082,6 +1306,22 @@ qup0_i2c6: i2c@998000 {
> status = "disabled";
> };
>
> + qup0_spi6: spi@998000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00998000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S6_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup0_i2c7: i2c@99c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x0099c000 0 0x4000>;
> @@ -1097,6 +1337,22 @@ qup0_i2c7: i2c@99c000 {
> interconnect-names = "qup-core", "qup-config", "qup-memory";
> status = "disabled";
> };
> +
> + qup0_spi7: spi@99c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x0099c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP2_S7_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_0 0 &clk_virt SLAVE_QUP_CORE_0 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
> + <&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> };
>
> qup1: geniqup@ac0000 {
> @@ -1129,6 +1385,22 @@ qup1_i2c8: i2c@a80000 {
> status = "disabled";
> };
>
> + qup1_spi8: spi@a80000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a80000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c9: i2c@a84000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a84000 0 0x4000>;
> @@ -1145,6 +1417,22 @@ qup1_i2c9: i2c@a84000 {
> status = "disabled";
> };
>
> + qup1_spi9: spi@a84000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a84000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c10: i2c@a88000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a88000 0 0x4000>;
> @@ -1161,6 +1449,22 @@ qup1_i2c10: i2c@a88000 {
> status = "disabled";
> };
>
> + qup1_spi10: spi@a88000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a88000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c11: i2c@a8c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a8c000 0 0x4000>;
> @@ -1177,6 +1481,22 @@ qup1_i2c11: i2c@a8c000 {
> status = "disabled";
> };
>
> + qup1_spi11: spi@a8c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a8c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c12: i2c@a90000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a90000 0 0x4000>;
> @@ -1193,6 +1513,22 @@ qup1_i2c12: i2c@a90000 {
> status = "disabled";
> };
>
> + qup1_spi12: spi@a90000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a90000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c13: i2c@a94000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a94000 0 0x4000>;
> @@ -1209,6 +1545,22 @@ qup1_i2c13: i2c@a94000 {
> status = "disabled";
> };
>
> + qup1_spi13: spi@a94000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a94000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c14: i2c@a98000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a98000 0 0x4000>;
> @@ -1225,6 +1577,22 @@ qup1_i2c14: i2c@a98000 {
> status = "disabled";
> };
>
> + qup1_spi14: spi@a98000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a98000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 835 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> +
> qup1_i2c15: i2c@a9c000 {
> compatible = "qcom,geni-i2c";
> reg = <0 0x00a9c000 0 0x4000>;
> @@ -1240,6 +1608,22 @@ qup1_i2c15: i2c@a9c000 {
> interconnect-names = "qup-core", "qup-config", "qup-memory";
> status = "disabled";
> };
> +
> + qup1_spi15: spi@a9c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0 0x00a9c000 0 0x4000>;
> + clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
> + clock-names = "se";
> + interrupts = <GIC_SPI 836 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interconnects = <&clk_virt MASTER_QUP_CORE_1 0 &clk_virt SLAVE_QUP_CORE_1 0>,
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
> + <&aggre1_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "qup-core", "qup-config", "qup-memory";
> + spi-max-frequency = <50000000>;
> + status = "disabled";
> + };
> };
>
> pcie4: pcie@1c00000 {
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
@ 2022-12-13 7:18 ` Shazad Hussain
2022-12-13 14:48 ` Konrad Dybcio
` (2 subsequent siblings)
3 siblings, 0 replies; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 7:18 UTC (permalink / raw)
To: Brian Masney, andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude
On 12/12/2022 11:53 PM, Brian Masney wrote:
> Add the necessary nodes in order to get qup1_i2c15 and qup2_i2c18
> functioning on the automotive board and exposed to userspace.
>
> This work was derived from various patches that Qualcomm delivered
> to Red Hat in a downstream kernel. This change was validated by using
> i2c-tools 4.3.3 on CentOS Stream 9:
>
> [root@localhost ~]# i2cdetect -l
> i2c-15 i2c Geni-I2C I2C adapter
> i2c-18 i2c Geni-I2C I2C adapter
>
> [root@localhost ~]# i2cdetect -a -y 15
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Bus 18 has the same output. I validated that we get the same output on
> the downstream kernel.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 46 +++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> index d70859803fbd..6dc3f3ff8ece 100644
> --- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> @@ -17,6 +17,8 @@ / {
> compatible = "qcom,sa8540p-ride", "qcom,sa8540p";
>
> aliases {
> + i2c15 = &qup1_i2c15;
> + i2c18 = &qup2_i2c18;
I was listing out all the i2c devices to be enabled apart from above and
below are applicable for Qdrive3 as well:
i2c0 980000
i2c1 984000
i2c12 0x00A90000
-Shazad
> serial0 = &qup2_uart17;
> };
>
> @@ -188,10 +190,28 @@ &pcie3a_phy {
> status = "okay";
> };
>
> +&qup1 {
> + status = "okay";
> +};
> +
> +&qup1_i2c15 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup1_i2c15_default>;
> +
> + status = "okay";
> +};
> +
> &qup2 {
> status = "okay";
> };
>
> +&qup2_i2c18 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup2_i2c18_default>;
> +
> + status = "okay";
> +};
> +
> &qup2_uart17 {
> compatible = "qcom,geni-debug-uart";
> status = "okay";
> @@ -313,4 +333,30 @@ wake-pins {
> bias-pull-up;
> };
> };
> +
> + qup1_i2c15_default: qup1-i2c15-state {
> + mux-pins {
> + pins = "gpio36", "gpio37";
> + function = "qup15";
> + };
> +
> + config-pins {
> + pins = "gpio36", "gpio37";
> + drive-strength = <0x02>;
> + bias-pull-up;
> + };
> + };
> +
> + qup2_i2c18_default: qup2-i2c18-state {
> + mux-pins {
> + pins = "gpio66", "gpio67";
> + function = "qup18";
> + };
> +
> + config-pins {
> + pins = "gpio66", "gpio67";
> + drive-strength = <0x02>;
> + bias-pull-up;
> + };
> + };
> };
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 7:16 ` Shazad Hussain
@ 2022-12-13 12:27 ` Brian Masney
2022-12-13 12:47 ` Mark Brown
2022-12-13 13:02 ` Krzysztof Kozlowski
0 siblings, 2 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-13 12:27 UTC (permalink / raw)
To: Shazad Hussain, Mark Brown
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, linux-spi, Javier Martinez Canillas
+ Mark Brown and linux-spi list
On Tue, Dec 13, 2022 at 12:46:18PM +0530, Shazad Hussain wrote:
> On 12/12/2022 11:53 PM, Brian Masney wrote:
> > Add the missing nodes for the spi buses that's present on this SoC.
> >
> > This work was derived from various patches that Qualcomm delivered
> > to Red Hat in a downstream kernel.
> >
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > ---
> > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
> > 1 file changed, 384 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > index 392a1509f0be..b50db09feae2 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > @@ -829,6 +829,22 @@ qup2_i2c16: i2c@880000 {
> > status = "disabled";
> > };
> > + qup2_spi16: spi@880000 {
> > + compatible = "qcom,geni-spi";
> > + reg = <0 0x00880000 0 0x4000>;
> > + clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
> > + clock-names = "se";
> > + interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
> > + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
> > + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
> > + interconnect-names = "qup-core", "qup-config", "qup-memory";
> > + spi-max-frequency = <50000000>;
>
> This is device property not host and same applicable for all below spi
> nodes.
> Also FYI let's enable below SPI for Qdrive usecases once spidev compatible
> name is confirmed.
> SE9 0x00A84000
> SE22 0x00898000
I talked to Javier Martinez Canillas yesterday about the spidev driver
and I think I now have a better understanding of what we need to do.
Quick background for Mark. For this automotive program, Qualcomm will be
delivering to Red Hat and our customers parts of the media stack in
userspace. This will be closed source, proprietary code that parts of it
will need to interface with SPI.
We can't add a generic qcom,spidev compatible to the spidev driver since
this is just a software abstraction. Instead, each type of device will
need to have it's own compatible that uniquely describes the type of
device. So you might have a compatible like qcom,spi-video-codec. There
will need to be a DT binding added that describes the hardware. I suspect
that a SPI device can simply be added to trivial-devices.yaml. Once the
DT binding is accepted, the compatible can be added to the spidev.c
driver. If an in-kernel driver is written in the future, then the
compatible can be moved from spidev to the new driver.
Mark: Is my understanding above correct? If so, will it be a problem to
get a compatible added to spidev.c if the corresponding userspace code is
closed source and proprietary?
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 12:27 ` Brian Masney
@ 2022-12-13 12:47 ` Mark Brown
2022-12-13 13:02 ` Krzysztof Kozlowski
1 sibling, 0 replies; 40+ messages in thread
From: Mark Brown @ 2022-12-13 12:47 UTC (permalink / raw)
To: Brian Masney
Cc: Shazad Hussain, andersson, krzysztof.kozlowski+dt, konrad.dybcio,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude, linux-spi, Javier Martinez Canillas
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Tue, Dec 13, 2022 at 07:27:01AM -0500, Brian Masney wrote:
> We can't add a generic qcom,spidev compatible to the spidev driver since
> this is just a software abstraction. Instead, each type of device will
> need to have it's own compatible that uniquely describes the type of
> device. So you might have a compatible like qcom,spi-video-codec. There
> will need to be a DT binding added that describes the hardware. I suspect
> that a SPI device can simply be added to trivial-devices.yaml. Once the
> DT binding is accepted, the compatible can be added to the spidev.c
> driver. If an in-kernel driver is written in the future, then the
> compatible can be moved from spidev to the new driver.
> Mark: Is my understanding above correct? If so, will it be a problem to
> get a compatible added to spidev.c if the corresponding userspace code is
> closed source and proprietary?
No restriction on what the userspace is.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 12:27 ` Brian Masney
2022-12-13 12:47 ` Mark Brown
@ 2022-12-13 13:02 ` Krzysztof Kozlowski
2022-12-13 13:08 ` Javier Martinez Canillas
1 sibling, 1 reply; 40+ messages in thread
From: Krzysztof Kozlowski @ 2022-12-13 13:02 UTC (permalink / raw)
To: Brian Masney, Shazad Hussain, Mark Brown
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, linux-spi, Javier Martinez Canillas
On 13/12/2022 13:27, Brian Masney wrote:
> + Mark Brown and linux-spi list
>
> On Tue, Dec 13, 2022 at 12:46:18PM +0530, Shazad Hussain wrote:
>> On 12/12/2022 11:53 PM, Brian Masney wrote:
>>> Add the missing nodes for the spi buses that's present on this SoC.
>>>
>>> This work was derived from various patches that Qualcomm delivered
>>> to Red Hat in a downstream kernel.
>>>
>>> Signed-off-by: Brian Masney <bmasney@redhat.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
>>> 1 file changed, 384 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> index 392a1509f0be..b50db09feae2 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> @@ -829,6 +829,22 @@ qup2_i2c16: i2c@880000 {
>>> status = "disabled";
>>> };
>>> + qup2_spi16: spi@880000 {
>>> + compatible = "qcom,geni-spi";
>>> + reg = <0 0x00880000 0 0x4000>;
>>> + clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
>>> + clock-names = "se";
>>> + interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
>>> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
>>> + <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
>>> + interconnect-names = "qup-core", "qup-config", "qup-memory";
>>> + spi-max-frequency = <50000000>;
>>
>> This is device property not host and same applicable for all below spi
>> nodes.
>> Also FYI let's enable below SPI for Qdrive usecases once spidev compatible
>> name is confirmed.
>> SE9 0x00A84000
>> SE22 0x00898000
>
> I talked to Javier Martinez Canillas yesterday about the spidev driver
> and I think I now have a better understanding of what we need to do.
> Quick background for Mark. For this automotive program, Qualcomm will be
> delivering to Red Hat and our customers parts of the media stack in
> userspace. This will be closed source, proprietary code that parts of it
> will need to interface with SPI.
>
> We can't add a generic qcom,spidev compatible to the spidev driver since
> this is just a software abstraction. Instead, each type of device will
> need to have it's own compatible that uniquely describes the type of
> device. So you might have a compatible like qcom,spi-video-codec. There
> will need to be a DT binding added that describes the hardware. I suspect
> that a SPI device can simply be added to trivial-devices.yaml. Once the
> DT binding is accepted, the compatible can be added to the spidev.c
> driver. If an in-kernel driver is written in the future, then the
> compatible can be moved from spidev to the new driver.
>
> Mark: Is my understanding above correct? If so, will it be a problem to
> get a compatible added to spidev.c if the corresponding userspace code is
> closed source and proprietary?
qcom,spi-video-codec is still not specific enough. You need to describe
real device behind spidev. To be clear - you do not describe userspace,
but the device.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 13:02 ` Krzysztof Kozlowski
@ 2022-12-13 13:08 ` Javier Martinez Canillas
2022-12-13 14:36 ` Brian Masney
0 siblings, 1 reply; 40+ messages in thread
From: Javier Martinez Canillas @ 2022-12-13 13:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Brian Masney, Shazad Hussain, Mark Brown
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, linux-spi
Hello Krzysztof,
Long time no see :)
On 12/13/22 14:02, Krzysztof Kozlowski wrote:
> On 13/12/2022 13:27, Brian Masney wrote:
[...]
>
> qcom,spi-video-codec is still not specific enough. You need to describe
> real device behind spidev. To be clear - you do not describe userspace,
> but the device.
>
Agree.
I believe Brian just used "qcom,spi-video-codec" as an example but is only
a make up name to illustrate the concept. QC needs to determine what would
be the correct <vendor,device> tuple for the IP block that the user-space
driver will drive.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 13:08 ` Javier Martinez Canillas
@ 2022-12-13 14:36 ` Brian Masney
2022-12-13 14:45 ` Shazad Hussain
0 siblings, 1 reply; 40+ messages in thread
From: Brian Masney @ 2022-12-13 14:36 UTC (permalink / raw)
To: Javier Martinez Canillas, Shazad Hussain
Cc: Krzysztof Kozlowski, Mark Brown, andersson,
krzysztof.kozlowski+dt, konrad.dybcio, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude,
linux-spi
On Tue, Dec 13, 2022 at 02:08:47PM +0100, Javier Martinez Canillas wrote:
> On 12/13/22 14:02, Krzysztof Kozlowski wrote:
> > On 13/12/2022 13:27, Brian Masney wrote:
> > qcom,spi-video-codec is still not specific enough. You need to describe
> > real device behind spidev. To be clear - you do not describe userspace,
> > but the device.
> >
>
> Agree.
>
> I believe Brian just used "qcom,spi-video-codec" as an example but is only
> a make up name to illustrate the concept. QC needs to determine what would
> be the correct <vendor,device> tuple for the IP block that the user-space
> driver will drive.
Yes, that was just an example.
Shazad: Is this thread clear about what QC needs for spidev? I'll let QC
take care of sending patch(es) to add the various compatibles since I'm
not sure what hardware will be backed by spidev.
I'll take care of making sure that sc8280xp.dtsi gets the spi controller
nodes added.
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
2022-12-13 14:36 ` Brian Masney
@ 2022-12-13 14:45 ` Shazad Hussain
0 siblings, 0 replies; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 14:45 UTC (permalink / raw)
To: Brian Masney, Javier Martinez Canillas
Cc: Krzysztof Kozlowski, Mark Brown, andersson,
krzysztof.kozlowski+dt, konrad.dybcio, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude,
linux-spi
On 12/13/2022 8:06 PM, Brian Masney wrote:
> On Tue, Dec 13, 2022 at 02:08:47PM +0100, Javier Martinez Canillas wrote:
>> On 12/13/22 14:02, Krzysztof Kozlowski wrote:
>>> On 13/12/2022 13:27, Brian Masney wrote:
>>> qcom,spi-video-codec is still not specific enough. You need to describe
>>> real device behind spidev. To be clear - you do not describe userspace,
>>> but the device.
>>>
>>
>> Agree.
>>
>> I believe Brian just used "qcom,spi-video-codec" as an example but is only
>> a make up name to illustrate the concept. QC needs to determine what would
>> be the correct <vendor,device> tuple for the IP block that the user-space
>> driver will drive.
>
> Yes, that was just an example.
>
> Shazad: Is this thread clear about what QC needs for spidev? I'll let QC
> take care of sending patch(es) to add the various compatibles since I'm
> not sure what hardware will be backed by spidev.
>
I think for qup2_spi22 we can use qcom,spi-msm-codec-slave as
compatible. As this is what used in downstream.
> I'll take care of making sure that sc8280xp.dtsi gets the spi controller
> nodes added.
Yes, for qup1_spi9 we can add it later when needed. This is for
display/touch 2nd.
Shazad
>
> Brian
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
2022-12-13 7:18 ` Shazad Hussain
@ 2022-12-13 14:48 ` Konrad Dybcio
2022-12-14 12:30 ` Brian Masney
2022-12-13 14:59 ` Johan Hovold
2022-12-14 12:51 ` Krzysztof Kozlowski
3 siblings, 1 reply; 40+ messages in thread
From: Konrad Dybcio @ 2022-12-13 14:48 UTC (permalink / raw)
To: Brian Masney, andersson, krzysztof.kozlowski+dt
Cc: robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude, quic_shazhuss
On 12.12.2022 19:23, Brian Masney wrote:
> Add the necessary nodes in order to get qup1_i2c15 and qup2_i2c18
> functioning on the automotive board and exposed to userspace.
>
> This work was derived from various patches that Qualcomm delivered
> to Red Hat in a downstream kernel. This change was validated by using
> i2c-tools 4.3.3 on CentOS Stream 9:
>
> [root@localhost ~]# i2cdetect -l
> i2c-15 i2c Geni-I2C I2C adapter
> i2c-18 i2c Geni-I2C I2C adapter
>
> [root@localhost ~]# i2cdetect -a -y 15
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Bus 18 has the same output. I validated that we get the same output on
> the downstream kernel.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 46 +++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> index d70859803fbd..6dc3f3ff8ece 100644
> --- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> @@ -17,6 +17,8 @@ / {
> compatible = "qcom,sa8540p-ride", "qcom,sa8540p";
>
> aliases {
> + i2c15 = &qup1_i2c15;
> + i2c18 = &qup2_i2c18;
> serial0 = &qup2_uart17;
> };
>
> @@ -188,10 +190,28 @@ &pcie3a_phy {
> status = "okay";
> };
>
> +&qup1 {
> + status = "okay";
> +};
> +
> +&qup1_i2c15 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup1_i2c15_default>;
> +
> + status = "okay";
> +};
> +
> &qup2 {
> status = "okay";
> };
>
> +&qup2_i2c18 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup2_i2c18_default>;
> +
> + status = "okay";
> +};
> +
> &qup2_uart17 {
> compatible = "qcom,geni-debug-uart";
> status = "okay";
> @@ -313,4 +333,30 @@ wake-pins {
> bias-pull-up;
> };
> };
> +
> + qup1_i2c15_default: qup1-i2c15-state {
You can drop mux/config-pins and have the pin properties live directly
under the qup1-i2cN-state node.
Konrad
> + mux-pins {
> + pins = "gpio36", "gpio37";
> + function = "qup15";
> + };
> +
> + config-pins {
> + pins = "gpio36", "gpio37";
> + drive-strength = <0x02>;
> + bias-pull-up;
> + };
> + };
> +
> + qup2_i2c18_default: qup2-i2c18-state {
> + mux-pins {
> + pins = "gpio66", "gpio67";
> + function = "qup18";
> + };
> +
> + config-pins {
> + pins = "gpio66", "gpio67";
> + drive-strength = <0x02>;
> + bias-pull-up;
> + };
> + };
> };
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
2022-12-12 18:48 ` Konrad Dybcio
@ 2022-12-13 14:54 ` Johan Hovold
2022-12-13 15:04 ` Shazad Hussain
` (3 more replies)
1 sibling, 4 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 14:54 UTC (permalink / raw)
To: Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
> According to the downstream 5.4 kernel sources for the sa8540p,
> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
> also match. Let's go ahead and correct the name that's used in the
> three files where this is listed.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 109c9d2b684d..875cc91324ce 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
> status = "disabled";
> };
>
> - qup2_i2c5: i2c@894000 {
> + qup2_i2c21: i2c@894000 {
Note that the node is labelled qup2_i2c5 and not qup_i2c5.
That is, the QUP nodes are labelled using two indices, and specifically
qup2_i2c5
would be another name for
qup_i2c21
if we'd been using such a flat naming scheme (there are 8 engines per
QUP).
So there's nothing wrong with how these nodes are currently named, but
mixing the two scheme as you are suggesting would not be correct.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
2022-12-13 7:18 ` Shazad Hussain
2022-12-13 14:48 ` Konrad Dybcio
@ 2022-12-13 14:59 ` Johan Hovold
2022-12-14 12:51 ` Krzysztof Kozlowski
3 siblings, 0 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 14:59 UTC (permalink / raw)
To: Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Mon, Dec 12, 2022 at 01:23:13PM -0500, Brian Masney wrote:
> Add the necessary nodes in order to get qup1_i2c15 and qup2_i2c18
> functioning on the automotive board and exposed to userspace.
>
> This work was derived from various patches that Qualcomm delivered
> to Red Hat in a downstream kernel. This change was validated by using
> i2c-tools 4.3.3 on CentOS Stream 9:
>
> [root@localhost ~]# i2cdetect -l
> i2c-15 i2c Geni-I2C I2C adapter
> i2c-18 i2c Geni-I2C I2C adapter
>
> [root@localhost ~]# i2cdetect -a -y 15
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Bus 18 has the same output. I validated that we get the same output on
> the downstream kernel.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> + qup1_i2c15_default: qup1-i2c15-state {
> + mux-pins {
> + pins = "gpio36", "gpio37";
> + function = "qup15";
> + };
> +
> + config-pins {
> + pins = "gpio36", "gpio37";
> + drive-strength = <0x02>;
Use decimal notation.
> + bias-pull-up;
> + };
> + };
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 14:54 ` Johan Hovold
@ 2022-12-13 15:04 ` Shazad Hussain
2022-12-13 15:19 ` Johan Hovold
2022-12-13 15:05 ` Brian Masney
` (2 subsequent siblings)
3 siblings, 1 reply; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 15:04 UTC (permalink / raw)
To: Johan Hovold, Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude
On 12/13/2022 8:24 PM, Johan Hovold wrote:
> On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
>> According to the downstream 5.4 kernel sources for the sa8540p,
>> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
>> also match. Let's go ahead and correct the name that's used in the
>> three files where this is listed.
>>
>> Signed-off-by: Brian Masney <bmasney@redhat.com>
>> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
>> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
>> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> index 109c9d2b684d..875cc91324ce 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
>> status = "disabled";
>> };
>>
>> - qup2_i2c5: i2c@894000 {
>> + qup2_i2c21: i2c@894000 {
>
> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>
> That is, the QUP nodes are labelled using two indices, and specifically
>
> qup2_i2c5
>
> would be another name for
>
> qup_i2c21
>
> if we'd been using such a flat naming scheme (there are 8 engines per
> QUP).
>
> So there's nothing wrong with how these nodes are currently named, but
> mixing the two scheme as you are suggesting would not be correct.
Wondering we might need to change qup2_uart17 to qup2_uart1 then ?
Shazad
>
> Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 14:54 ` Johan Hovold
2022-12-13 15:04 ` Shazad Hussain
@ 2022-12-13 15:05 ` Brian Masney
2022-12-13 15:12 ` Brian Masney
2022-12-13 15:17 ` Johan Hovold
3 siblings, 0 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-13 15:05 UTC (permalink / raw)
To: Johan Hovold
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>
> That is, the QUP nodes are labelled using two indices, and specifically
>
> qup2_i2c5
>
> would be another name for
>
> qup_i2c21
>
> if we'd been using such a flat naming scheme (there are 8 engines per
> QUP).
>
> So there's nothing wrong with how these nodes are currently named, but
> mixing the two scheme as you are suggesting would not be correct.
OK, I see; that makes sense. I'll drop this patch in v2 and fix up the
new nodes accordingly. Thank you for the explanation!
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 14:54 ` Johan Hovold
2022-12-13 15:04 ` Shazad Hussain
2022-12-13 15:05 ` Brian Masney
@ 2022-12-13 15:12 ` Brian Masney
2022-12-13 15:28 ` Johan Hovold
2022-12-13 15:17 ` Johan Hovold
3 siblings, 1 reply; 40+ messages in thread
From: Brian Masney @ 2022-12-13 15:12 UTC (permalink / raw)
To: Johan Hovold
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>
> That is, the QUP nodes are labelled using two indices, and specifically
>
> qup2_i2c5
>
> would be another name for
>
> qup_i2c21
>
> if we'd been using such a flat naming scheme (there are 8 engines per
> QUP).
>
> So there's nothing wrong with how these nodes are currently named, but
> mixing the two scheme as you are suggesting would not be correct.
Hi Johan,
What would I use for the name in the aliases section? Right now I have:
aliases {
i2c18 = &qup2_i2c18;
}
So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
the alias like so?
aliases {
i2c18 = &qup2_i2c2;
}
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 14:54 ` Johan Hovold
` (2 preceding siblings ...)
2022-12-13 15:12 ` Brian Masney
@ 2022-12-13 15:17 ` Johan Hovold
2022-12-13 15:29 ` Konrad Dybcio
3 siblings, 1 reply; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:17 UTC (permalink / raw)
To: Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
> > According to the downstream 5.4 kernel sources for the sa8540p,
> > i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
> > also match. Let's go ahead and correct the name that's used in the
> > three files where this is listed.
> >
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> > Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> > Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
>
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > index 109c9d2b684d..875cc91324ce 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> > @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
> > status = "disabled";
> > };
> >
> > - qup2_i2c5: i2c@894000 {
> > + qup2_i2c21: i2c@894000 {
>
> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>
> That is, the QUP nodes are labelled using two indices, and specifically
>
> qup2_i2c5
>
> would be another name for
>
> qup_i2c21
>
> if we'd been using such a flat naming scheme (there are 8 engines per
> QUP).
>
> So there's nothing wrong with how these nodes are currently named, but
> mixing the two scheme as you are suggesting would not be correct.
It appears sc8280xp is the only qcom platform using a qup prefix (even
if some older platform use a blsp equivalent), and we're not even using
it consistently as we, for example, have both
qup2_uart17, and
qup2_i2c5
(where the former should have been qup2_uart1).
So either we fix up the current labels or just drop the qup prefixes and
use a flat naming scheme (e.g. uart17 and i2c21).
Either way, there's no need for any Fixes tags as this isn't a bug.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:04 ` Shazad Hussain
@ 2022-12-13 15:19 ` Johan Hovold
0 siblings, 0 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:19 UTC (permalink / raw)
To: Shazad Hussain
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, konrad.dybcio,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On Tue, Dec 13, 2022 at 08:34:56PM +0530, Shazad Hussain wrote:
>
>
> On 12/13/2022 8:24 PM, Johan Hovold wrote:
> > On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
> >> According to the downstream 5.4 kernel sources for the sa8540p,
> >> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
> >> also match. Let's go ahead and correct the name that's used in the
> >> three files where this is listed.
> >>
> >> Signed-off-by: Brian Masney <bmasney@redhat.com>
> >> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> >> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> >> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
> >
> >> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >> index 109c9d2b684d..875cc91324ce 100644
> >> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
> >> status = "disabled";
> >> };
> >>
> >> - qup2_i2c5: i2c@894000 {
> >> + qup2_i2c21: i2c@894000 {
> >
> > Note that the node is labelled qup2_i2c5 and not qup_i2c5.
> >
> > That is, the QUP nodes are labelled using two indices, and specifically
> >
> > qup2_i2c5
> >
> > would be another name for
> >
> > qup_i2c21
> >
> > if we'd been using such a flat naming scheme (there are 8 engines per
> > QUP).
> >
> > So there's nothing wrong with how these nodes are currently named, but
> > mixing the two scheme as you are suggesting would not be correct.
>
> Wondering we might need to change qup2_uart17 to qup2_uart1 then ?
Right, I just noticed that too.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:12 ` Brian Masney
@ 2022-12-13 15:28 ` Johan Hovold
2022-12-13 15:34 ` Shazad Hussain
0 siblings, 1 reply; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:28 UTC (permalink / raw)
To: Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 10:12:57AM -0500, Brian Masney wrote:
> On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> > Note that the node is labelled qup2_i2c5 and not qup_i2c5.
> >
> > That is, the QUP nodes are labelled using two indices, and specifically
> >
> > qup2_i2c5
> >
> > would be another name for
> >
> > qup_i2c21
> >
> > if we'd been using such a flat naming scheme (there are 8 engines per
> > QUP).
> >
> > So there's nothing wrong with how these nodes are currently named, but
> > mixing the two scheme as you are suggesting would not be correct.
>
> Hi Johan,
>
> What would I use for the name in the aliases section? Right now I have:
>
> aliases {
> i2c18 = &qup2_i2c18;
> }
>
> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
> the alias like so?
>
> aliases {
> i2c18 = &qup2_i2c2;
> }
Or perhaps the i2c controllers should use a zero-based index instead of
being named after the serial engines (e.g. as we do for the console
uart).
How are they named in the schematics?
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:17 ` Johan Hovold
@ 2022-12-13 15:29 ` Konrad Dybcio
2022-12-13 15:32 ` Johan Hovold
0 siblings, 1 reply; 40+ messages in thread
From: Konrad Dybcio @ 2022-12-13 15:29 UTC (permalink / raw)
To: Johan Hovold, Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude,
quic_shazhuss
On 13.12.2022 16:17, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
>> On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
>>> According to the downstream 5.4 kernel sources for the sa8540p,
>>> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
>>> also match. Let's go ahead and correct the name that's used in the
>>> three files where this is listed.
>>>
>>> Signed-off-by: Brian Masney <bmasney@redhat.com>
>>> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
>>> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
>>> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> index 109c9d2b684d..875cc91324ce 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
>>> status = "disabled";
>>> };
>>>
>>> - qup2_i2c5: i2c@894000 {
>>> + qup2_i2c21: i2c@894000 {
>>
>> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>>
>> That is, the QUP nodes are labelled using two indices, and specifically
>>
>> qup2_i2c5
>>
>> would be another name for
>>
>> qup_i2c21
>>
>> if we'd been using such a flat naming scheme (there are 8 engines per
>> QUP).
>>
>> So there's nothing wrong with how these nodes are currently named, but
>> mixing the two scheme as you are suggesting would not be correct.
>
> It appears sc8280xp is the only qcom platform using a qup prefix (even
> if some older platform use a blsp equivalent), and we're not even using
> it consistently as we, for example, have both
>
> qup2_uart17, and
> qup2_i2c5
>
> (where the former should have been qup2_uart1).
>
> So either we fix up the current labels or just drop the qup prefixes and
> use a flat naming scheme (e.g. uart17 and i2c21).
Oh, I didn't notice that! I suppose sticking with i2cN as we've been
doing ever since i2c-geni was introduced sounds like the best option..
Konrad
>
> Either way, there's no need for any Fixes tags as this isn't a bug.
>
> Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:29 ` Konrad Dybcio
@ 2022-12-13 15:32 ` Johan Hovold
2022-12-13 15:59 ` Brian Masney
0 siblings, 1 reply; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:32 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 04:29:04PM +0100, Konrad Dybcio wrote:
>
>
> On 13.12.2022 16:17, Johan Hovold wrote:
> > On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> >> On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
> >>> According to the downstream 5.4 kernel sources for the sa8540p,
> >>> i2c@894000 is labeled i2c bus 21, not 5. The interrupts and clocks
> >>> also match. Let's go ahead and correct the name that's used in the
> >>> three files where this is listed.
> >>>
> >>> Signed-off-by: Brian Masney <bmasney@redhat.com>
> >>> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> >>> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> >>> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
> >>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> index 109c9d2b684d..875cc91324ce 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> >>> @@ -827,7 +827,7 @@ qup2_uart17: serial@884000 {
> >>> status = "disabled";
> >>> };
> >>>
> >>> - qup2_i2c5: i2c@894000 {
> >>> + qup2_i2c21: i2c@894000 {
> >>
> >> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
> >>
> >> That is, the QUP nodes are labelled using two indices, and specifically
> >>
> >> qup2_i2c5
> >>
> >> would be another name for
> >>
> >> qup_i2c21
> >>
> >> if we'd been using such a flat naming scheme (there are 8 engines per
> >> QUP).
> >>
> >> So there's nothing wrong with how these nodes are currently named, but
> >> mixing the two scheme as you are suggesting would not be correct.
> >
> > It appears sc8280xp is the only qcom platform using a qup prefix (even
> > if some older platform use a blsp equivalent), and we're not even using
> > it consistently as we, for example, have both
> >
> > qup2_uart17, and
> > qup2_i2c5
> >
> > (where the former should have been qup2_uart1).
> >
> > So either we fix up the current labels or just drop the qup prefixes and
> > use a flat naming scheme (e.g. uart17 and i2c21).
> Oh, I didn't notice that! I suppose sticking with i2cN as we've been
> doing ever since i2c-geni was introduced sounds like the best option..
Yeah, sounds good to me.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:28 ` Johan Hovold
@ 2022-12-13 15:34 ` Shazad Hussain
2022-12-13 15:39 ` Johan Hovold
0 siblings, 1 reply; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 15:34 UTC (permalink / raw)
To: Johan Hovold, Brian Masney
Cc: andersson, krzysztof.kozlowski+dt, konrad.dybcio, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude
On 12/13/2022 8:58 PM, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 10:12:57AM -0500, Brian Masney wrote:
>> On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
>>> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>>>
>>> That is, the QUP nodes are labelled using two indices, and specifically
>>>
>>> qup2_i2c5
>>>
>>> would be another name for
>>>
>>> qup_i2c21
>>>
>>> if we'd been using such a flat naming scheme (there are 8 engines per
>>> QUP).
>>>
>>> So there's nothing wrong with how these nodes are currently named, but
>>> mixing the two scheme as you are suggesting would not be correct.
>>
>> Hi Johan,
>>
>> What would I use for the name in the aliases section? Right now I have:
>>
>> aliases {
>> i2c18 = &qup2_i2c18;
>> }
>>
>> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
>> the alias like so?
>>
>> aliases {
>> i2c18 = &qup2_i2c2;
>> }
>
> Or perhaps the i2c controllers should use a zero-based index instead of
> being named after the serial engines (e.g. as we do for the console
> uart).
>
> How are they named in the schematics?
>
We should use from 0 to N.
Shazad
> Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:34 ` Shazad Hussain
@ 2022-12-13 15:39 ` Johan Hovold
2022-12-13 15:42 ` Johan Hovold
2022-12-13 15:45 ` Shazad Hussain
0 siblings, 2 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:39 UTC (permalink / raw)
To: Shazad Hussain
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, konrad.dybcio,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On Tue, Dec 13, 2022 at 09:04:39PM +0530, Shazad Hussain wrote:
>
>
> On 12/13/2022 8:58 PM, Johan Hovold wrote:
> > On Tue, Dec 13, 2022 at 10:12:57AM -0500, Brian Masney wrote:
> >> On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
> >>> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
> >>>
> >>> That is, the QUP nodes are labelled using two indices, and specifically
> >>>
> >>> qup2_i2c5
> >>>
> >>> would be another name for
> >>>
> >>> qup_i2c21
> >>>
> >>> if we'd been using such a flat naming scheme (there are 8 engines per
> >>> QUP).
> >>>
> >>> So there's nothing wrong with how these nodes are currently named, but
> >>> mixing the two scheme as you are suggesting would not be correct.
> >>
> >> Hi Johan,
> >>
> >> What would I use for the name in the aliases section? Right now I have:
> >>
> >> aliases {
> >> i2c18 = &qup2_i2c18;
> >> }
> >>
> >> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
> >> the alias like so?
> >>
> >> aliases {
> >> i2c18 = &qup2_i2c2;
> >> }
> >
> > Or perhaps the i2c controllers should use a zero-based index instead of
> > being named after the serial engines (e.g. as we do for the console
> > uart).
> >
> > How are they named in the schematics?
>
> We should use from 0 to N.
With N being 23 after the number of serial engines, or the number of
available i2c buses on a particular board minus one?
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:39 ` Johan Hovold
@ 2022-12-13 15:42 ` Johan Hovold
2022-12-13 15:44 ` Konrad Dybcio
2022-12-13 15:45 ` Shazad Hussain
1 sibling, 1 reply; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 15:42 UTC (permalink / raw)
To: Shazad Hussain
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, konrad.dybcio,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On Tue, Dec 13, 2022 at 04:39:54PM +0100, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 09:04:39PM +0530, Shazad Hussain wrote:
> > On 12/13/2022 8:58 PM, Johan Hovold wrote:
> > >> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
> > >> the alias like so?
> > >>
> > >> aliases {
> > >> i2c18 = &qup2_i2c2;
> > >> }
> > >
> > > Or perhaps the i2c controllers should use a zero-based index instead of
> > > being named after the serial engines (e.g. as we do for the console
> > > uart).
> > >
> > > How are they named in the schematics?
> >
> > We should use from 0 to N.
>
> With N being 23 after the number of serial engines, or the number of
> available i2c buses on a particular board minus one?
Looks like the more recent Qualcomm platforms use aliases that reflect
the engine number (i.e. 0 to 23) for i2c and spi.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:42 ` Johan Hovold
@ 2022-12-13 15:44 ` Konrad Dybcio
2022-12-13 16:15 ` Johan Hovold
0 siblings, 1 reply; 40+ messages in thread
From: Konrad Dybcio @ 2022-12-13 15:44 UTC (permalink / raw)
To: Johan Hovold, Shazad Hussain
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude
On 13.12.2022 16:42, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 04:39:54PM +0100, Johan Hovold wrote:
>> On Tue, Dec 13, 2022 at 09:04:39PM +0530, Shazad Hussain wrote:
>>> On 12/13/2022 8:58 PM, Johan Hovold wrote:
>
>>>>> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
>>>>> the alias like so?
>>>>>
>>>>> aliases {
>>>>> i2c18 = &qup2_i2c2;
>>>>> }
>>>>
>>>> Or perhaps the i2c controllers should use a zero-based index instead of
>>>> being named after the serial engines (e.g. as we do for the console
>>>> uart).
>>>>
>>>> How are they named in the schematics?
>>>
>>> We should use from 0 to N.
>>
>> With N being 23 after the number of serial engines, or the number of
>> available i2c buses on a particular board minus one?
>
> Looks like the more recent Qualcomm platforms use aliases that reflect
> the engine number (i.e. 0 to 23) for i2c and spi.
IMO it makes the most sense, as it tells the userspace "hello, this
device is connected to the physical I2Cn on the SoC" as opposed to
"hello, this device is connected to the nth enabled bus on this
particular board".
Konrad
>
> Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:39 ` Johan Hovold
2022-12-13 15:42 ` Johan Hovold
@ 2022-12-13 15:45 ` Shazad Hussain
1 sibling, 0 replies; 40+ messages in thread
From: Shazad Hussain @ 2022-12-13 15:45 UTC (permalink / raw)
To: Johan Hovold
Cc: Brian Masney, andersson, krzysztof.kozlowski+dt, konrad.dybcio,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On 12/13/2022 9:09 PM, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 09:04:39PM +0530, Shazad Hussain wrote:
>>
>>
>> On 12/13/2022 8:58 PM, Johan Hovold wrote:
>>> On Tue, Dec 13, 2022 at 10:12:57AM -0500, Brian Masney wrote:
>>>> On Tue, Dec 13, 2022 at 03:54:05PM +0100, Johan Hovold wrote:
>>>>> Note that the node is labelled qup2_i2c5 and not qup_i2c5.
>>>>>
>>>>> That is, the QUP nodes are labelled using two indices, and specifically
>>>>>
>>>>> qup2_i2c5
>>>>>
>>>>> would be another name for
>>>>>
>>>>> qup_i2c21
>>>>>
>>>>> if we'd been using such a flat naming scheme (there are 8 engines per
>>>>> QUP).
>>>>>
>>>>> So there's nothing wrong with how these nodes are currently named, but
>>>>> mixing the two scheme as you are suggesting would not be correct.
>>>>
>>>> Hi Johan,
>>>>
>>>> What would I use for the name in the aliases section? Right now I have:
>>>>
>>>> aliases {
>>>> i2c18 = &qup2_i2c18;
>>>> }
>>>>
>>>> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
>>>> the alias like so?
>>>>
>>>> aliases {
>>>> i2c18 = &qup2_i2c2;
>>>> }
>>>
>>> Or perhaps the i2c controllers should use a zero-based index instead of
>>> being named after the serial engines (e.g. as we do for the console
>>> uart).
>>>
>>> How are they named in the schematics?
>>
>> We should use from 0 to N.
>
> With N being 23 after the number of serial engines, or the number of
> available i2c buses on a particular board minus one?
>
wrt to serial engine number starting from 0.
Shazad
> Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:32 ` Johan Hovold
@ 2022-12-13 15:59 ` Brian Masney
2022-12-13 16:22 ` Johan Hovold
0 siblings, 1 reply; 40+ messages in thread
From: Brian Masney @ 2022-12-13 15:59 UTC (permalink / raw)
To: Johan Hovold
Cc: Konrad Dybcio, andersson, krzysztof.kozlowski+dt, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 04:32:43PM +0100, Johan Hovold wrote:
> On Tue, Dec 13, 2022 at 04:29:04PM +0100, Konrad Dybcio wrote:
> > On 13.12.2022 16:17, Johan Hovold wrote:
> > > It appears sc8280xp is the only qcom platform using a qup prefix (even
> > > if some older platform use a blsp equivalent), and we're not even using
> > > it consistently as we, for example, have both
> > >
> > > qup2_uart17, and
> > > qup2_i2c5
> > >
> > > (where the former should have been qup2_uart1).
> > >
> > > So either we fix up the current labels or just drop the qup prefixes and
> > > use a flat naming scheme (e.g. uart17 and i2c21).
>
> > Oh, I didn't notice that! I suppose sticking with i2cN as we've been
> > doing ever since i2c-geni was introduced sounds like the best option..
>
> Yeah, sounds good to me.
This makes sense and I'll fix up the existing geni nodes and my new
nodes in v2.
I noticed another inconsistency with sc8280xp.dtsi compared to other
platforms. I left off all of the pin mappings in sc8280xp.dtsi and
added them to the sa8540-ride.dts file since the existing sc8280xp.dtsi
file contains no pin mappings. Other platforms such as sm8450.dtsi,
sm8350.dtsi, and sm8250.dtsi contain the geni pin mappings. My
understanding is that these geni pins are fixed within the SoC and
don't change with the different boards. Should I also add the geni
pin mappings to sc8280xp.dtsi?
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:44 ` Konrad Dybcio
@ 2022-12-13 16:15 ` Johan Hovold
0 siblings, 0 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 16:15 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Shazad Hussain, Brian Masney, andersson, krzysztof.kozlowski+dt,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On Tue, Dec 13, 2022 at 04:44:15PM +0100, Konrad Dybcio wrote:
>
>
> On 13.12.2022 16:42, Johan Hovold wrote:
> > On Tue, Dec 13, 2022 at 04:39:54PM +0100, Johan Hovold wrote:
> >> On Tue, Dec 13, 2022 at 09:04:39PM +0530, Shazad Hussain wrote:
> >>> On 12/13/2022 8:58 PM, Johan Hovold wrote:
> >
> >>>>> So qup2_i2c18 becomes qup2_i2c2. Would I use the flat naming scheme for
> >>>>> the alias like so?
> >>>>>
> >>>>> aliases {
> >>>>> i2c18 = &qup2_i2c2;
> >>>>> }
> >>>>
> >>>> Or perhaps the i2c controllers should use a zero-based index instead of
> >>>> being named after the serial engines (e.g. as we do for the console
> >>>> uart).
> >>>>
> >>>> How are they named in the schematics?
> >>>
> >>> We should use from 0 to N.
> >>
> >> With N being 23 after the number of serial engines, or the number of
> >> available i2c buses on a particular board minus one?
> >
> > Looks like the more recent Qualcomm platforms use aliases that reflect
> > the engine number (i.e. 0 to 23) for i2c and spi.
> IMO it makes the most sense, as it tells the userspace "hello, this
> device is connected to the physical I2Cn on the SoC" as opposed to
> "hello, this device is connected to the nth enabled bus on this
> particular board".
But I guess it still depends on the board. I wouldn't expect a product
with four serial ports to use the engine numbers on labels for the
connectors for example.
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21
2022-12-13 15:59 ` Brian Masney
@ 2022-12-13 16:22 ` Johan Hovold
0 siblings, 0 replies; 40+ messages in thread
From: Johan Hovold @ 2022-12-13 16:22 UTC (permalink / raw)
To: Brian Masney
Cc: Konrad Dybcio, andersson, krzysztof.kozlowski+dt, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude, quic_shazhuss
On Tue, Dec 13, 2022 at 10:59:47AM -0500, Brian Masney wrote:
> I noticed another inconsistency with sc8280xp.dtsi compared to other
> platforms. I left off all of the pin mappings in sc8280xp.dtsi and
> added them to the sa8540-ride.dts file since the existing sc8280xp.dtsi
> file contains no pin mappings. Other platforms such as sm8450.dtsi,
> sm8350.dtsi, and sm8250.dtsi contain the geni pin mappings. My
> understanding is that these geni pins are fixed within the SoC and
> don't change with the different boards. Should I also add the geni
> pin mappings to sc8280xp.dtsi?
The pins are fixed but the pin configuration is still board specific.
This came up earlier and we decided that keeping all pin configuration
in the board dts was the way to go (e.g. for consistency and as it
allows the integrator to easily review the actual configuration).
Johan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-13 14:48 ` Konrad Dybcio
@ 2022-12-14 12:30 ` Brian Masney
2022-12-14 12:52 ` Krzysztof Kozlowski
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-14 12:30 UTC (permalink / raw)
To: Konrad Dybcio, quic_shazhuss
Cc: andersson, krzysztof.kozlowski+dt, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude
On Tue, Dec 13, 2022 at 03:48:27PM +0100, Konrad Dybcio wrote:
> > + qup1_i2c15_default: qup1-i2c15-state {
> > + mux-pins {
> > + pins = "gpio36", "gpio37";
> > + function = "qup15";
> > + };
> > +
> > + config-pins {
> > + pins = "gpio36", "gpio37";
> > + drive-strength = <0x02>;
> > + bias-pull-up;
> > + };
> > + };
>
> You can drop mux/config-pins and have the pin properties live directly
> under the qup1-i2cN-state node.
Hi Konrad (and Shazad below),
I need to enable 5 i2c buses (0, 1, 12, 15, 18) on this board. I tried
the following combinations with the pin mapping configuration and the
only one that seems to work reliably for me is what I originally had.
With the following, only 2 out of the 5 buses are detected. There's no
i2c mesages in dmesg.
i2c0_default: i2c0-default-state {
pins = "gpio135", "gpio136";
function = "qup15";
};
Next, I added a drive-strength and bias-pull-up. All 5 buses are
detected. One bus throws read errors when I probe it with i2cdetect, two
others 'i2cdetect -a -y $BUSNUM' takes ~5 seconds to run, and the
remaining two are fast.
i2c0_default: i2c0-default-state {
pins = "gpio135", "gpio136";
function = "qup15";
drive-strength = <2>;
bias-pull-up;
};
This is the style where i2cdetect seems to be happy for all 5 buses and
is fast:
i2c0_default: i2c0-default-state {
mux-pins {
pins = "gpio135", "gpio136";
function = "qup0";
};
config-pins {
pins = "gpio135", "gpio136";
drive-strength = <2>;
bias-pull-up;
};
};
Shazad: 'i2cdetect -a -y $BUSNUM) shows that all 5 buses have the same
addresses listening. Is that expected? That seems a bit odd to me.
[root@localhost ~]# i2cdetect -a -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
0 1 2 3 4 5 6 7 8 9 a b c d e f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:
I triple checked that I have the QUP pins defined correctly for the 5
buses. I checked them against what's in the downstream kernel and I also
checked them against what's in upstream's
drivers/pinctrl/qcom/pinctrl-sc8280xp.c. This is the pin mapping that I
have:
i2c0: gpio135, gpio136
i2c1: gpio158, gpio159
i2c12: gpio0, gpio1
i2c15: gpio36, gpio37
i2c18: gpio66, gpio67
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
` (2 preceding siblings ...)
2022-12-13 14:59 ` Johan Hovold
@ 2022-12-14 12:51 ` Krzysztof Kozlowski
3 siblings, 0 replies; 40+ messages in thread
From: Krzysztof Kozlowski @ 2022-12-14 12:51 UTC (permalink / raw)
To: Brian Masney, andersson, krzysztof.kozlowski+dt
Cc: konrad.dybcio, robh+dt, johan+linaro, linux-arm-msm, devicetree,
linux-kernel, ahalaney, echanude, quic_shazhuss
On 12/12/2022 19:23, Brian Masney wrote:
> Add the necessary nodes in order to get qup1_i2c15 and qup2_i2c18
> functioning on the automotive board and exposed to userspace.
>
> This work was derived from various patches that Qualcomm delivered
> to Red Hat in a downstream kernel. This change was validated by using
> i2c-tools 4.3.3 on CentOS Stream 9:
>
> [root@localhost ~]# i2cdetect -l
> i2c-15 i2c Geni-I2C I2C adapter
> i2c-18 i2c Geni-I2C I2C adapter
>
> [root@localhost ~]# i2cdetect -a -y 15
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Bus 18 has the same output. I validated that we get the same output on
> the downstream kernel.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 46 +++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> index d70859803fbd..6dc3f3ff8ece 100644
> --- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
> @@ -17,6 +17,8 @@ / {
> compatible = "qcom,sa8540p-ride", "qcom,sa8540p";
>
> aliases {
> + i2c15 = &qup1_i2c15;
> + i2c18 = &qup2_i2c18;
> serial0 = &qup2_uart17;
> };
>
> @@ -188,10 +190,28 @@ &pcie3a_phy {
> status = "okay";
> };
>
> +&qup1 {
> + status = "okay";
> +};
> +
> +&qup1_i2c15 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup1_i2c15_default>;
> +
> + status = "okay";
> +};
> +
> &qup2 {
> status = "okay";
> };
>
> +&qup2_i2c18 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup2_i2c18_default>;
> +
> + status = "okay";
> +};
> +
> &qup2_uart17 {
> compatible = "qcom,geni-debug-uart";
> status = "okay";
> @@ -313,4 +333,30 @@ wake-pins {
> bias-pull-up;
> };
> };
> +
> + qup1_i2c15_default: qup1-i2c15-state {
> + mux-pins {
> + pins = "gpio36", "gpio37";
> + function = "qup15";
> + };
> +
> + config-pins {
> + pins = "gpio36", "gpio37";
> + drive-strength = <0x02>;
Except the problem pointed out by Konrad (we do not have separate mux
and config pins anymore), this is not a hex, it's mA.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-14 12:30 ` Brian Masney
@ 2022-12-14 12:52 ` Krzysztof Kozlowski
2022-12-14 14:19 ` Brian Masney
2022-12-14 12:53 ` Konrad Dybcio
2022-12-14 15:36 ` Shazad Hussain
2 siblings, 1 reply; 40+ messages in thread
From: Krzysztof Kozlowski @ 2022-12-14 12:52 UTC (permalink / raw)
To: Brian Masney, Konrad Dybcio, quic_shazhuss
Cc: andersson, krzysztof.kozlowski+dt, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude
On 14/12/2022 13:30, Brian Masney wrote:
> On Tue, Dec 13, 2022 at 03:48:27PM +0100, Konrad Dybcio wrote:
>>> + qup1_i2c15_default: qup1-i2c15-state {
>>> + mux-pins {
>>> + pins = "gpio36", "gpio37";
>>> + function = "qup15";
>>> + };
>>> +
>>> + config-pins {
>>> + pins = "gpio36", "gpio37";
>>> + drive-strength = <0x02>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>
>> You can drop mux/config-pins and have the pin properties live directly
>> under the qup1-i2cN-state node.
>
> Hi Konrad (and Shazad below),
>
> I need to enable 5 i2c buses (0, 1, 12, 15, 18) on this board. I tried
> the following combinations with the pin mapping configuration and the
> only one that seems to work reliably for me is what I originally had.
>
> With the following, only 2 out of the 5 buses are detected. There's no
> i2c mesages in dmesg.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> };
>
> Next, I added a drive-strength and bias-pull-up. All 5 buses are
> detected. One bus throws read errors when I probe it with i2cdetect, two
> others 'i2cdetect -a -y $BUSNUM' takes ~5 seconds to run, and the
> remaining two are fast.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> drive-strength = <2>;
> bias-pull-up;
> };
>
> This is the style where i2cdetect seems to be happy for all 5 buses and
> is fast:
>
> i2c0_default: i2c0-default-state {
> mux-pins {
> pins = "gpio135", "gpio136";
> function = "qup0";
> };
>
> config-pins {
> pins = "gpio135", "gpio136";
> drive-strength = <2>;
> bias-pull-up;
> };
> };
>
>
> Shazad: 'i2cdetect -a -y $BUSNUM) shows that all 5 buses have the same
> addresses listening. Is that expected? That seems a bit odd to me.
>
> [root@localhost ~]# i2cdetect -a -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> I triple checked that I have the QUP pins defined correctly for the 5
> buses. I checked them against what's in the downstream kernel and I also
> checked them against what's in upstream's
> drivers/pinctrl/qcom/pinctrl-sc8280xp.c. This is the pin mapping that I
What's the base of this kernel? Are you sure you have d21f4b7ffc22?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-14 12:30 ` Brian Masney
2022-12-14 12:52 ` Krzysztof Kozlowski
@ 2022-12-14 12:53 ` Konrad Dybcio
2022-12-14 15:36 ` Shazad Hussain
2 siblings, 0 replies; 40+ messages in thread
From: Konrad Dybcio @ 2022-12-14 12:53 UTC (permalink / raw)
To: Brian Masney, quic_shazhuss
Cc: andersson, krzysztof.kozlowski+dt, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude
On 14.12.2022 13:30, Brian Masney wrote:
> On Tue, Dec 13, 2022 at 03:48:27PM +0100, Konrad Dybcio wrote:
>>> + qup1_i2c15_default: qup1-i2c15-state {
>>> + mux-pins {
>>> + pins = "gpio36", "gpio37";
>>> + function = "qup15";
>>> + };
>>> +
>>> + config-pins {
>>> + pins = "gpio36", "gpio37";
>>> + drive-strength = <0x02>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>
>> You can drop mux/config-pins and have the pin properties live directly
>> under the qup1-i2cN-state node.
>
> Hi Konrad (and Shazad below),
>
> I need to enable 5 i2c buses (0, 1, 12, 15, 18) on this board. I tried
> the following combinations with the pin mapping configuration and the
> only one that seems to work reliably for me is what I originally had.
>
> With the following, only 2 out of the 5 buses are detected. There's no
> i2c mesages in dmesg.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> };
>
> Next, I added a drive-strength and bias-pull-up. All 5 buses are
> detected. One bus throws read errors when I probe it with i2cdetect, two
> others 'i2cdetect -a -y $BUSNUM' takes ~5 seconds to run, and the
> remaining two are fast.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> drive-strength = <2>;
> bias-pull-up;
> };
>
> This is the style where i2cdetect seems to be happy for all 5 buses and
> is fast:
>
> i2c0_default: i2c0-default-state {
> mux-pins {
> pins = "gpio135", "gpio136";
> function = "qup0";
> };
>
> config-pins {
> pins = "gpio135", "gpio136";
> drive-strength = <2>;
> bias-pull-up;
> };
> };
Unless you made a typo somewhere, I genuinely have no explanation for this..
Konrad
>
>
> Shazad: 'i2cdetect -a -y $BUSNUM) shows that all 5 buses have the same
> addresses listening. Is that expected? That seems a bit odd to me.
>
> [root@localhost ~]# i2cdetect -a -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> I triple checked that I have the QUP pins defined correctly for the 5
> buses. I checked them against what's in the downstream kernel and I also
> checked them against what's in upstream's
> drivers/pinctrl/qcom/pinctrl-sc8280xp.c. This is the pin mapping that I
> have:
>
> i2c0: gpio135, gpio136
> i2c1: gpio158, gpio159
> i2c12: gpio0, gpio1
> i2c15: gpio36, gpio37
> i2c18: gpio66, gpio67
>
> Brian
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-14 12:52 ` Krzysztof Kozlowski
@ 2022-12-14 14:19 ` Brian Masney
0 siblings, 0 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-14 14:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, quic_shazhuss, andersson, krzysztof.kozlowski+dt,
robh+dt, johan+linaro, linux-arm-msm, devicetree, linux-kernel,
ahalaney, echanude
On Wed, Dec 14, 2022 at 01:52:17PM +0100, Krzysztof Kozlowski wrote:
> On 14/12/2022 13:30, Brian Masney wrote:
> > I triple checked that I have the QUP pins defined correctly for the 5
> > buses. I checked them against what's in the downstream kernel and I also
> > checked them against what's in upstream's
> > drivers/pinctrl/qcom/pinctrl-sc8280xp.c. This is the pin mapping that I
>
> What's the base of this kernel? Are you sure you have d21f4b7ffc22?
I'm based on top of linux-next-20221208 with no other changes. I have
that commit.
commit d21f4b7ffc22c009da925046b69b15af08de9d75
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Oct 14 10:33:18 2022 -0700
pinctrl: qcom: Avoid glitching lines when we first mux to output
On Wed, Dec 14, 2022 at 01:53:38PM +0100, Konrad Dybcio wrote:
> > This is the style where i2cdetect seems to be happy for all 5 buses and
> > is fast:
> >
> > i2c0_default: i2c0-default-state {
> > mux-pins {
> > pins = "gpio135", "gpio136";
> > function = "qup0";
> > };
> >
> > config-pins {
> > pins = "gpio135", "gpio136";
> > drive-strength = <2>;
> > bias-pull-up;
> > };
> > };
> Unless you made a typo somewhere, I genuinely have no explanation for this..
I have my unpublished v2 patch set committed to my tree and a clean tree
according to git. I started with the state that I have quoted above. As I
did the various tests I described in my last email, I would do a
'git diff' just to be sure that I didn't have any typos.
I'll wait to hear from Shazad about whether or not the output that I got
from i2cdetect is supposed to be the same for those 5 buses.
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-14 12:30 ` Brian Masney
2022-12-14 12:52 ` Krzysztof Kozlowski
2022-12-14 12:53 ` Konrad Dybcio
@ 2022-12-14 15:36 ` Shazad Hussain
2022-12-14 16:24 ` Brian Masney
2 siblings, 1 reply; 40+ messages in thread
From: Shazad Hussain @ 2022-12-14 15:36 UTC (permalink / raw)
To: Brian Masney, Konrad Dybcio
Cc: andersson, krzysztof.kozlowski+dt, robh+dt, johan+linaro,
linux-arm-msm, devicetree, linux-kernel, ahalaney, echanude
On 12/14/2022 6:00 PM, Brian Masney wrote:
> On Tue, Dec 13, 2022 at 03:48:27PM +0100, Konrad Dybcio wrote:
>>> + qup1_i2c15_default: qup1-i2c15-state {
>>> + mux-pins {
>>> + pins = "gpio36", "gpio37";
>>> + function = "qup15";
>>> + };
>>> +
>>> + config-pins {
>>> + pins = "gpio36", "gpio37";
>>> + drive-strength = <0x02>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>
>> You can drop mux/config-pins and have the pin properties live directly
>> under the qup1-i2cN-state node.
>
> Hi Konrad (and Shazad below),
>
> I need to enable 5 i2c buses (0, 1, 12, 15, 18) on this board. I tried
> the following combinations with the pin mapping configuration and the
> only one that seems to work reliably for me is what I originally had.
>
> With the following, only 2 out of the 5 buses are detected. There's no
> i2c mesages in dmesg.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> };
>
> Next, I added a drive-strength and bias-pull-up. All 5 buses are
> detected. One bus throws read errors when I probe it with i2cdetect, two
> others 'i2cdetect -a -y $BUSNUM' takes ~5 seconds to run, and the
This I have also observed on downstream as well, where scanning all
addresses takes some amount of time near to 5-6 seconds.
> remaining two are fast.
>
> i2c0_default: i2c0-default-state {
> pins = "gpio135", "gpio136";
> function = "qup15";
> drive-strength = <2>;
> bias-pull-up;
> };
>
This is the default config we should use.
> This is the style where i2cdetect seems to be happy for all 5 buses and
> is fast:
>
> i2c0_default: i2c0-default-state {
> mux-pins {
> pins = "gpio135", "gpio136";
> function = "qup0";
> };
>
> config-pins {
> pins = "gpio135", "gpio136";
> drive-strength = <2>;
> bias-pull-up;
> };
> };
>
>
> Shazad: 'i2cdetect -a -y $BUSNUM) shows that all 5 buses have the same
> addresses listening. Is that expected? That seems a bit odd to me.
>
Brian, even I haven't checked with all enabled, let me check this on
other projects and with downstream as well and get back to you.
-Shazad
> [root@localhost ~]# i2cdetect -a -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> I triple checked that I have the QUP pins defined correctly for the 5
> buses. I checked them against what's in the downstream kernel and I also
> checked them against what's in upstream's
> drivers/pinctrl/qcom/pinctrl-sc8280xp.c. This is the pin mapping that I
> have:
>
> i2c0: gpio135, gpio136
> i2c1: gpio158, gpio159
> i2c12: gpio0, gpio1
> i2c15: gpio36, gpio37
> i2c18: gpio66, gpio67
>
> Brian
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes
2022-12-14 15:36 ` Shazad Hussain
@ 2022-12-14 16:24 ` Brian Masney
0 siblings, 0 replies; 40+ messages in thread
From: Brian Masney @ 2022-12-14 16:24 UTC (permalink / raw)
To: Shazad Hussain
Cc: Konrad Dybcio, andersson, krzysztof.kozlowski+dt, robh+dt,
johan+linaro, linux-arm-msm, devicetree, linux-kernel, ahalaney,
echanude
On Wed, Dec 14, 2022 at 09:06:48PM +0530, Shazad Hussain wrote:
> > i2c0_default: i2c0-default-state {
> > pins = "gpio135", "gpio136";
> > function = "qup15";
> > drive-strength = <2>;
> > bias-pull-up;
> > };
> >
>
> This is the default config we should use.
OK, I'll stick with this config.
> > Shazad: 'i2cdetect -a -y $BUSNUM) shows that all 5 buses have the same
> > addresses listening. Is that expected? That seems a bit odd to me.
> >
>
> Brian, even I haven't checked with all enabled, let me check this on other
> projects and with downstream as well and get back to you.
I'll post my v2 in a little bit so that you can test it.
Brian
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2022-12-14 16:25 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-12 18:23 [PATCH 0/4] arm64: dts: qcom: sc8280xp: add i2c and spi nodes Brian Masney
2022-12-12 18:23 ` [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21 Brian Masney
2022-12-12 18:48 ` Konrad Dybcio
2022-12-13 14:54 ` Johan Hovold
2022-12-13 15:04 ` Shazad Hussain
2022-12-13 15:19 ` Johan Hovold
2022-12-13 15:05 ` Brian Masney
2022-12-13 15:12 ` Brian Masney
2022-12-13 15:28 ` Johan Hovold
2022-12-13 15:34 ` Shazad Hussain
2022-12-13 15:39 ` Johan Hovold
2022-12-13 15:42 ` Johan Hovold
2022-12-13 15:44 ` Konrad Dybcio
2022-12-13 16:15 ` Johan Hovold
2022-12-13 15:45 ` Shazad Hussain
2022-12-13 15:17 ` Johan Hovold
2022-12-13 15:29 ` Konrad Dybcio
2022-12-13 15:32 ` Johan Hovold
2022-12-13 15:59 ` Brian Masney
2022-12-13 16:22 ` Johan Hovold
2022-12-12 18:23 ` [PATCH 2/4] arm64: dts: qcom: sc8280xp: add missing i2c nodes Brian Masney
2022-12-12 18:23 ` [PATCH 3/4] arm64: dts: qcom: sa8540p-ride: add qup1_i2c15 and qup2_i2c18 nodes Brian Masney
2022-12-13 7:18 ` Shazad Hussain
2022-12-13 14:48 ` Konrad Dybcio
2022-12-14 12:30 ` Brian Masney
2022-12-14 12:52 ` Krzysztof Kozlowski
2022-12-14 14:19 ` Brian Masney
2022-12-14 12:53 ` Konrad Dybcio
2022-12-14 15:36 ` Shazad Hussain
2022-12-14 16:24 ` Brian Masney
2022-12-13 14:59 ` Johan Hovold
2022-12-14 12:51 ` Krzysztof Kozlowski
2022-12-12 18:23 ` [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes Brian Masney
2022-12-13 7:16 ` Shazad Hussain
2022-12-13 12:27 ` Brian Masney
2022-12-13 12:47 ` Mark Brown
2022-12-13 13:02 ` Krzysztof Kozlowski
2022-12-13 13:08 ` Javier Martinez Canillas
2022-12-13 14:36 ` Brian Masney
2022-12-13 14:45 ` Shazad Hussain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).