| Message ID | 20210902214708.1776690-1-robimarko@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: qcom: ipq8074: add SMEM support | expand |
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 >
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
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
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
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 --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>;
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(+)