arm64: dts: qcom: ipq8074: add SMEM support

PATCH Superseded Robert Marko 4 participants 12 messages Sep 2, 2021 – Oct 6, 2021

Subsystems (3)

Device tree bindings Arm Qualcomm mailing list Arm Qualcomm support

lore

Share & tools

lore

Robert Marko

author

2021-09-02 21:47 UTC #0 lore raw

PATCH 1/1 arm64: dts: qcom: ipq8074: add SMEM support

IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.

Signed-off-by Robert Marko <[email protected]>

---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

arch/arm64/boot/dts/qcom/ipq8074.dtsi +28 -0

index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		smem_region: memory@4ab00000 {
+			no-map;
+			reg = <0x0 0x4ab00000 0x0 0x00100000>;
+		};
+	};
+
+	tcsr_mutex: hwlock {
+		compatible = "qcom,tcsr-mutex";
+		syscon = <&tcsr_mutex_regs 0 0x80>;
+		#hwlock-cells = <1>;
+	};
+
+	smem {
+		compatible = "qcom,smem";
+		memory-region = <&smem_region>;
+		hwlocks = <&tcsr_mutex 0>;
+	};
+
 	soc: soc {
 		#address-cells = <0x1>;
 		#size-cells = <0x1>;

@@ -293,6 +316,11 @@ gcc: gcc@1800000 {
 			#reset-cells = <0x1>;
 		};
 
+		tcsr_mutex_regs: syscon@1905000 {
+			compatible = "syscon";
+			reg = <0x01905000 0x8000>;
+		};
+
 		sdhc_1: sdhci@7824900 {
 			compatible = "qcom,sdhci-msm-v4";
 			reg = <0x7824900 0x500>, <0x7824000 0x800>;

Signature · 1 line

2.31.1

Bjorn Andersson

2021-09-20 02:52 UTC #1 lore raw

Quoted 4 lines · Robert Marko

IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>

Thanks for your patch Robert.

Quoted 16 lines

---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0

index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
 		};
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;

arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98

Quoted 10 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0

+
+		smem_region: memory@4ab00000 {
+			no-map;
+			reg = <0x0 0x4ab00000 0x0 0x00100000>;
+		};
+	};
+
+	tcsr_mutex: hwlock {
+		compatible = "qcom,tcsr-mutex";
+		syscon = <&tcsr_mutex_regs 0 0x80>;

Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.

So can you please respin accordingly?

Thanks,
Bjorn

Quoted 27 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +14 -0

+		#hwlock-cells = <1>;
+	};
+
+	smem {
+		compatible = "qcom,smem";
+		memory-region = <&smem_region>;
+		hwlocks = <&tcsr_mutex 0>;
+	};
+
 	soc: soc {
 		#address-cells = <0x1>;
 		#size-cells = <0x1>;

@@ -293,6 +316,11 @@ gcc: gcc@1800000 {
 			#reset-cells = <0x1>;
 		};
 
+		tcsr_mutex_regs: syscon@1905000 {
+			compatible = "syscon";
+			reg = <0x01905000 0x8000>;
+		};
+
 		sdhc_1: sdhci@7824900 {
 			compatible = "qcom,sdhci-msm-v4";
 			reg = <0x7824900 0x500>, <0x7824000 0x800>;

Signature · 1 line

2.31.1

Robert Marko

author

2021-09-20 09:26 UTC #2 lore raw

Quoted 42 lines · Bjorn Andersson

Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.

Quoted 1 line

So can you please respin accordingly?

Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;

Is the whole TCSR range as I don't have docs?

Regards,
Robert

Quoted 31 lines

Thanks,
Bjorn

Quoted 27 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +14 -1

+             #hwlock-cells = <1>;
+     };
+
+     smem {
+             compatible = "qcom,smem";
+             memory-region = <&smem_region>;
+             hwlocks = <&tcsr_mutex 0>;
+     };
+
      soc: soc {
              #address-cells = <0x1>;
              #size-cells = <0x1>;

@@ -293,6 +316,11 @@ gcc: gcc@1800000 {
                      #reset-cells = <0x1>;
              };
 
+             tcsr_mutex_regs: syscon@1905000 {
+                     compatible = "syscon";
+                     reg = <0x01905000 0x8000>;
+             };
+
              sdhc_1: sdhci@7824900 {
                      compatible = "qcom,sdhci-msm-v4";
                      reg = <0x7824900 0x500>, <0x7824000 0x800>;
--

2.31.1

Kathiravan T

2021-09-21 06:24 UTC #3 lore raw

Quoted 44 lines · Robert Marko

Quoted 42 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.

Quoted 6 lines

Quoted 1 line
So can you please respin accordingly?
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?

Robert,

TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)

Thanks,
Kathiravan T.

Quoted 34 lines

Regards,
Robert

Quoted 31 lines

Thanks,
Bjorn

Quoted 27 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +14 -1

+             #hwlock-cells = <1>;
+     };
+
+     smem {
+             compatible = "qcom,smem";
+             memory-region = <&smem_region>;
+             hwlocks = <&tcsr_mutex 0>;
+     };
+
      soc: soc {
              #address-cells = <0x1>;
              #size-cells = <0x1>;

@@ -293,6 +316,11 @@ gcc: gcc@1800000 {
                      #reset-cells = <0x1>;
              };
 
+             tcsr_mutex_regs: syscon@1905000 {
+                     compatible = "syscon";
+                     reg = <0x01905000 0x8000>;
+             };
+
              sdhc_1: sdhci@7824900 {
                      compatible = "qcom,sdhci-msm-v4";
                      reg = <0x7824900 0x500>, <0x7824000 0x800>;
--

2.31.1

Signature · 1 line

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Robert Marko

author

2021-09-22 20:23 UTC #4 lore raw

Quoted 49 lines · Kathiravan T

Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?

Quoted 8 lines

Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)

Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.

For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.

Now, I have no idea why does this variant which uses MMIO regmap probe so much later?

Regards,
Robert

Quoted 42 lines

Thanks,
Kathiravan T.

Quoted 23 lines

Regards,
Robert

Quoted 20 lines

Thanks,
Bjorn

Quoted 16 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +9 -0

+             #hwlock-cells = <1>;
+     };
+
+     smem {
+             compatible = "qcom,smem";
+             memory-region = <&smem_region>;
+             hwlocks = <&tcsr_mutex 0>;
+     };
+
      soc: soc {
              #address-cells = <0x1>;
              #size-cells = <0x1>;

@@ -293,6 +316,11 @@ gcc: gcc@1800000 {
                      #reset-cells = <0x1>;
              };

Quoted 11 lines

arch/arm64/boot/dts/qcom/ipq8074.dtsi +5 -1

+             tcsr_mutex_regs: syscon@1905000 {
+                     compatible = "syscon";
+                     reg = <0x01905000 0x8000>;
+             };
+
              sdhc_1: sdhci@7824900 {
                      compatible = "qcom,sdhci-msm-v4";
                      reg = <0x7824900 0x500>, <0x7824000 0x800>;
--

2.31.1

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Bjorn Andersson

2021-09-22 22:18 UTC #5 lore raw

Quoted 63 lines · Robert Marko

Quoted 49 lines · Kathiravan T
Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?
Quoted 8 lines
Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)
Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.

Quoted 9 lines

For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.
Now, I have no idea why does this variant which uses MMIO regmap probe so much later?

Mani, do you have any input related to the probe deferral of the SMEM partition parser, because SMEM not yet probed?

Thanks,
Bjorn

Robert Marko

author

2021-10-06 18:05 UTC #6 lore raw

Quoted 72 lines · Bjorn Andersson

Quoted 69 lines · Robert Marko
Quoted 49 lines · Kathiravan T
Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?
Quoted 8 lines
Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)
Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.
For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.

Quoted 6 lines

Quoted 3 lines
Now, I have no idea why does this variant which uses MMIO regmap probe so much later?
Mani, do you have any input related to the probe deferral of the SMEM partition parser, because SMEM not yet probed?

I did some more digging as it made no sense to me and it looks like it gets to driver_deferred_probe_add()
but then gets stuck in the mutex_lock() after which it resets the board without any kind of error.
I can see that it gets to this mutex_lock():
https://elixir.bootlin.com/linux/v5.15-rc4/source/drivers/base/dd.c#L136

So, this is some weird bug unrelated to the SMEM itself, but it's an annoying one as it resets the board.
I am now kind of stuck debugging it further, this is beyond my capabilities.

Regards,
Robert

Quoted 3 lines

Thanks,
Bjorn

Robert Marko

author

2021-10-06 18:13 UTC #7 lore raw

Quoted 82 lines · Robert Marko

Quoted 72 lines · Bjorn Andersson
Quoted 69 lines · Robert Marko
Quoted 49 lines · Kathiravan T
Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?
Quoted 8 lines
Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)
Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.
For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.
Quoted 6 lines
Quoted 3 lines
Now, I have no idea why does this variant which uses MMIO regmap probe so much later?
Mani, do you have any input related to the probe deferral of the SMEM partition parser, because SMEM not yet probed?

Quoted 6 lines

I did some more digging as it made no sense to me and it looks like it gets to driver_deferred_probe_add()
but then gets stuck in the mutex_lock() after which it resets the board without any kind of error.
I can see that it gets to this mutex_lock():
https://elixir.bootlin.com/linux/v5.15-rc4/source/drivers/base/dd.c#L136

Scratch that, it was a printing issue I can see the SMEM and NAND drivers being added to the probe deferral list but it resets after the NAND driver gets added.
Only if it would print a trace and not just reset.

Regards,
Robert

Quoted 11 lines

So, this is some weird bug unrelated to the SMEM itself, but it's an annoying one as it resets the board.
I am now kind of stuck debugging it further, this is beyond my capabilities.
Regards,
Robert
Quoted 3 lines
Thanks,
Bjorn

Manivannan Sadhasivam

2021-10-06 18:24 UTC #8 lore raw

In reply to Bjorn Andersson

Quoted 71 lines · Bjorn Andersson

Quoted 69 lines · Robert Marko
Quoted 49 lines · Kathiravan T
Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?
Quoted 8 lines
Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)
Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.
For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.

Quoted 7 lines

Quoted 3 lines
Now, I have no idea why does this variant which uses MMIO regmap probe so much later?
Mani, do you have any input related to the probe deferral of the SMEM partition parser, because SMEM not yet probed?

Sorry, missed this earlier. I did face the probe deferral issue before and submitted a small series for fixing that:

https://lore.kernel.org/linux-mtd/[email protected]/

These 2 patches are in mainline now. Robert, can you make sure that you have these 2 patches in your tree?

Thanks,
Mani

Quoted 2 lines

Thanks,
Bjorn

Robert Marko

author

2021-10-06 18:26 UTC #9 lore raw

Quoted 81 lines · Manivannan Sadhasivam

Quoted 71 lines · Bjorn Andersson
Quoted 69 lines · Robert Marko
Quoted 49 lines · Kathiravan T
Quoted 47 lines · Robert Marko
Quoted 44 lines · Bjorn Andersson
Quoted 4 lines · Robert Marko
IPQ8074 uses SMEM like other modern QCA SoC-s, so since its already supported by the kernel add the required DT nodes.
Signed-off-by Robert Marko <[email protected]>
Thanks for your patch Robert.
Quoted 16 lines
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +4 -0
index a620ac0d0b19..83e9243046aa 100644
@@ -82,6 +82,29 @@ scm {
              };
      };
 
+     reserved-memory {
+             #address-cells = <2>;
+             #size-cells = <2>;
+             ranges;
arch/arm64/boot/dts/qcom/ipq8074.dtsi scm { · line 98
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq8074.dtsi +10 -0
+
+             smem_region: memory@4ab00000 {
+                     no-map;
+                     reg = <0x0 0x4ab00000 0x0 0x00100000>;
+             };
+     };
+
+     tcsr_mutex: hwlock {
+             compatible = "qcom,tcsr-mutex";
+             syscon = <&tcsr_mutex_regs 0 0x80>;
Since it's not okay to have a lone "syscon" and I didn't think it was worth coming up with a binding for the TCSR mutex "syscon" I rewrote the
binding a while back. As such qcom,tcsr-mutex should now live in /soc directly.
So can you please respin accordingly?
Quoted 8 lines
Quoted 4 lines
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Robert,
TCSR_MUTEX block starts from 0x01905000 and has size 0x20000 (128KB)
Thanks, Kathiravan,
TSCR mutex with MMIO reg under it works, but there is some weird probe ordering issue.
For whatever reason, SMEM will get probed only after MTD does and this will cause issues
if SMEM parser is used as it will return -EPROBE_DEFER but the MTD core does not really
handle it correctly and causes the device to reboot after failed parsing.
Quoted 7 lines
Quoted 3 lines
Now, I have no idea why does this variant which uses MMIO regmap probe so much later?
Mani, do you have any input related to the probe deferral of the SMEM partition parser, because SMEM not yet probed?

Quoted 7 lines

Sorry, missed this earlier. I did face the probe deferral issue before and submitted a small series for fixing that:
https://lore.kernel.org/linux-mtd/[email protected]/
These 2 patches are in mainline now. Robert, can you make sure that you have these 2 patches in your tree?

Hi Mani,
Yes, I have those patches as I am running this on top of 5.15-rc4 currently.

Regards,
Robert

Quoted 6 lines

Thanks,
Mani
Quoted 2 lines
Thanks,
Bjorn

Manivannan Sadhasivam

2021-10-06 18:44 UTC #10 lore raw

Quoted 3 lines · Robert Marko

Quoted 1 line · Manivannan Sadhasivam

[...]

Quoted 11 lines

Quoted 7 lines
Sorry, missed this earlier. I did face the probe deferral issue before and submitted a small series for fixing that:
https://lore.kernel.org/linux-mtd/[email protected]/
These 2 patches are in mainline now. Robert, can you make sure that you have these 2 patches in your tree?
Hi Mani,
Yes, I have those patches as I am running this on top of 5.15-rc4 currently.

Hmm. So if both SMEM and NAND drivers are added to the probe deferral list then the issue is likely not related to probe ordering.

Can you nail down the point where the board starts rebooting?

Thanks,
Mani

Quoted 8 lines

Regards,
Robert
Quoted 6 lines
Thanks,
Mani
Quoted 2 lines
Thanks,
Bjorn

Robert Marko

author

2021-10-06 19:09 UTC #11 lore raw

Quoted 16 lines · Manivannan Sadhasivam

Quoted 3 lines · Robert Marko
Quoted 1 line · Manivannan Sadhasivam
[...]
Quoted 8 lines
Quoted 7 lines
Sorry, missed this earlier. I did face the probe deferral issue before and submitted a small series for fixing that:
https://lore.kernel.org/linux-mtd/[email protected]/
These 2 patches are in mainline now. Robert, can you make sure that you have these 2 patches in your tree?

Quoted 8 lines

Quoted 3 lines
Hi Mani,
Yes, I have those patches as I am running this on top of 5.15-rc4 currently.
Hmm. So if both SMEM and NAND drivers are added to the probe deferral list then the issue is likely not related to probe ordering.
Can you nail down the point where the board starts rebooting?

Unfortunately not, I can see that it resets after the NAND driver requesting probe deferral but I cannot pinpoint the exact thing that resets it
as there is no stack trace.

Regards,
Robert

Quoted 12 lines

Thanks,
Mani
Quoted 8 lines
Regards,
Robert
Quoted 6 lines
Thanks,
Mani
Quoted 2 lines
Thanks,
Bjorn