diff mbox series

arm64: dts: qcom: ipq8074: add SMEM support

Message ID 20210902214708.1776690-1-robimarko@gmail.com (mailing list archive)
State Changes Requested
Headers show
Series arm64: dts: qcom: ipq8074: add SMEM support | expand

Commit Message

Robert Marko Sept. 2, 2021, 9:47 p.m. UTC
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 <robimarko@gmail.com>
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

Comments

Bjorn Andersson Sept. 20, 2021, 2:52 a.m. UTC | #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 <robimarko@gmail.com>

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
>
Robert Marko Sept. 20, 2021, 9:25 a.m. UTC | #2
On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
<bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
>
> 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
> >
Kathiravan T Sept. 21, 2021, 6:24 a.m. UTC | #3
On 2021-09-20 14:55, Robert Marko wrote:
> On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
>> 
>> 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
>> >
Robert Marko Sept. 22, 2021, 8:23 p.m. UTC | #4
On Tue, 21 Sept 2021 at 08:24, Kathiravan T <kathirav@codeaurora.org> wrote:
>
> On 2021-09-20 14:55, Robert Marko wrote:
> > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> >>
> >> 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
Bjorn Andersson Sept. 22, 2021, 10:18 p.m. UTC | #5
On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:

> On Tue, 21 Sept 2021 at 08:24, Kathiravan T <kathirav@codeaurora.org> wrote:
> >
> > On 2021-09-20 14:55, Robert Marko wrote:
> > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> > >>
> > >> 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
Robert Marko Oct. 6, 2021, 6:05 p.m. UTC | #6
On Thu, 23 Sept 2021 at 00:18, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
>
> > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <kathirav@codeaurora.org> wrote:
> > >
> > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> > > >>
> > > >> 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
Robert Marko Oct. 6, 2021, 6:13 p.m. UTC | #7
On Wed, 6 Oct 2021 at 20:05, Robert Marko <robimarko@gmail.com> wrote:
>
> On Thu, 23 Sept 2021 at 00:18, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Wed 22 Sep 15:23 CDT 2021, Robert Marko wrote:
> >
> > > On Tue, 21 Sept 2021 at 08:24, Kathiravan T <kathirav@codeaurora.org> wrote:
> > > >
> > > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> > > > >>
> > > > >> 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
Manivannan Sadhasivam Oct. 6, 2021, 6:24 p.m. UTC | #8
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 <kathirav@codeaurora.org> wrote:
> > >
> > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> > > >>
> > > >> 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/20210302132757.225395-1-manivannan.sadhasivam@linaro.org/

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
Robert Marko Oct. 6, 2021, 6:26 p.m. UTC | #9
On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> 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 <kathirav@codeaurora.org> wrote:
> > > >
> > > > On 2021-09-20 14:55, Robert Marko wrote:
> > > > > On Mon, 20 Sept 2021 at 04:52, Bjorn Andersson
> > > > > <bjorn.andersson@linaro.org> 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 <robimarko@gmail.com>
> > > > >>
> > > > >> 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/20210302132757.225395-1-manivannan.sadhasivam@linaro.org/
>
> 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
Manivannan Sadhasivam Oct. 6, 2021, 6:44 p.m. UTC | #10
On Wed, Oct 06, 2021 at 08:26:10PM +0200, Robert Marko wrote:
> On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> 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/20210302132757.225395-1-manivannan.sadhasivam@linaro.org/
> >
> > 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
Robert Marko Oct. 6, 2021, 7:09 p.m. UTC | #11
On Wed, 6 Oct 2021 at 20:44, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Wed, Oct 06, 2021 at 08:26:10PM +0200, Robert Marko wrote:
> > On Wed, 6 Oct 2021 at 20:24, Manivannan Sadhasivam
> > <manivannan.sadhasivam@linaro.org> 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/20210302132757.225395-1-manivannan.sadhasivam@linaro.org/
> > >
> > > 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
diff mbox series

Patch

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>;