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(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a620ac0d0b19..83e9243046aa 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -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>;
--
2.31.1
On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> 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.
> ---
> arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> index a620ac0d0b19..83e9243046aa 100644
> --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> @@ -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>;
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
> + #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
>
On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
<[email protected]> wrote:
>
> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
>
> > 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.
>
> > ---
> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > index a620ac0d0b19..83e9243046aa 100644
> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > @@ -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>;
>
> 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?
Sure, can you just confirm that the:
reg = <0x01905000 0x8000>;
Is the whole TCSR range as I don't have docs?
Regards,
Robert
>
> Thanks,
> Bjorn
>
> > + #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
> >
On 2021-09-20 14:55, Robert Marko wrote:
> On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> <[email protected]> wrote:
>>
>> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
>>
>> > 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.
>>
>> > ---
>> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
>> > 1 file changed, 28 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
>> > index a620ac0d0b19..83e9243046aa 100644
>> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
>> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
>> > @@ -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>;
>>
>> 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?
>
> 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.
>
> Regards,
> Robert
>>
>> Thanks,
>> Bjorn
>>
>> > + #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
>> >
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
>
> On 2021-09-20 14:55, Robert Marko wrote:
> > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > <[email protected]> wrote:
> >>
> >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> >>
> >> > 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.
> >>
> >> > ---
> >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> >> > 1 file changed, 28 insertions(+)
> >> >
> >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> > index a620ac0d0b19..83e9243046aa 100644
> >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> > @@ -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>;
> >>
> >> 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?
> >
> > 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
>
> Thanks,
> Kathiravan T.
>
> >
> > Regards,
> > Robert
> >>
> >> Thanks,
> >> Bjorn
> >>
> >> > + #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
> >> >
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of Code Aurora Forum, hosted by The Linux Foundation
On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
> On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
> >
> > On 2021-09-20 14:55, Robert Marko wrote:
> > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > <[email protected]> wrote:
> > >>
> > >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> > >>
> > >> > 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.
> > >>
> > >> > ---
> > >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > >> > 1 file changed, 28 insertions(+)
> > >> >
> > >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > >> > index a620ac0d0b19..83e9243046aa 100644
> > >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > >> > @@ -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>;
> > >>
> > >> 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?
> > >
> > > 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?
>
Mani, do you have any input related to the probe deferral of the SMEM
partition parser, because SMEM not yet probed?
Thanks,
Bjorn
On Thu, 23 Sept 2021 at 00:18, Bjorn Andersson
<[email protected]> wrote:
>
> On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
>
> > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
> > >
> > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > <[email protected]> wrote:
> > > >>
> > > >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> > > >>
> > > >> > 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.
> > > >>
> > > >> > ---
> > > >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > > >> > 1 file changed, 28 insertions(+)
> > > >> >
> > > >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > index a620ac0d0b19..83e9243046aa 100644
> > > >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > @@ -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>;
> > > >>
> > > >> 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?
> > > >
> > > > 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?
> >
>
> 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
>
> Thanks,
> Bjorn
On Wed, 6 Oct 2021 at 20:05, Robert Marko <[email protected]> wrote:
>
> On Thu, 23 Sept 2021 at 00:18, Bjorn Andersson
> <[email protected]> wrote:
> >
> > On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
> >
> > > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
> > > >
> > > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > > <[email protected]> wrote:
> > > > >>
> > > > >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> > > > >>
> > > > >> > 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.
> > > > >>
> > > > >> > ---
> > > > >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > > > >> > 1 file changed, 28 insertions(+)
> > > > >> >
> > > > >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > index a620ac0d0b19..83e9243046aa 100644
> > > > >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > @@ -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>;
> > > > >>
> > > > >> 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?
> > > > >
> > > > > 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?
> > >
> >
> > 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
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
>
> 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
>
> >
> > Thanks,
> > Bjorn
On Wed, Sep 22, 2021 at 05:18:16PM -0500, Bjorn Andersson wrote:
> On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
>
> > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
> > >
> > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > <[email protected]> wrote:
> > > >>
> > > >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> > > >>
> > > >> > 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.
> > > >>
> > > >> > ---
> > > >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > > >> > 1 file changed, 28 insertions(+)
> > > >> >
> > > >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > index a620ac0d0b19..83e9243046aa 100644
> > > >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > >> > @@ -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>;
> > > >>
> > > >> 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?
> > > >
> > > > 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?
> >
>
> 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
> Thanks,
> Bjorn
On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
<[email protected]> wrote:
>
> On Wed, Sep 22, 2021 at 05:18:16PM -0500, Bjorn Andersson wrote:
> > On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
> >
> > > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <[email protected]> wrote:
> > > >
> > > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > > <[email protected]> wrote:
> > > > >>
> > > > >> On Thu 02 Sep 16:47 CDT 2021, Robert Marko wrote:
> > > > >>
> > > > >> > 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.
> > > > >>
> > > > >> > ---
> > > > >> > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
> > > > >> > 1 file changed, 28 insertions(+)
> > > > >> >
> > > > >> > diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > index a620ac0d0b19..83e9243046aa 100644
> > > > >> > --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> > > > >> > @@ -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>;
> > > > >>
> > > > >> 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?
> > > > >
> > > > > 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?
> > >
> >
> > 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?
Hi Mani,
Yes, I have those patches as I am running this on top of 5.15-rc4 currently.
Regards,
Robert
>
> Thanks,
> Mani
>
> > Thanks,
> > Bjorn
On Wed, Oct 06, 2021 at 08:26:10PM +0200, Robert Marko wrote:
> On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
> <[email protected]> wrote:
> >
[...]
> > 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
> Regards,
> Robert
> >
> > Thanks,
> > Mani
> >
> > > Thanks,
> > > Bjorn
On Wed, 6 Oct 2021 at 20:44, Manivannan Sadhasivam
<[email protected]> wrote:
>
> On Wed, Oct 06, 2021 at 08:26:10PM +0200, Robert Marko wrote:
> > On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
> > <[email protected]> wrote:
> > >
>
> [...]
>
> > > 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?
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
>
> Thanks,
> Mani
>
> > Regards,
> > Robert
> > >
> > > Thanks,
> > > Mani
> > >
> > > > Thanks,
> > > > Bjorn