[PATCH 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

[Daniel Baluta]

On Tue, Sep 12, 2023 at 12:54 PM Iuliana Prodan <iuliana.prodan at nxp.com> wrote:
>
> On 9/12/2023 11:26 AM, Krzysztof Kozlowski wrote:
> > On 12/09/2023 10:13, Iuliana Prodan wrote:
> >> On 9/12/2023 10:07 AM, Krzysztof Kozlowski wrote:
> >>> On 12/09/2023 00:44, Iuliana Prodan (OSS) wrote:
> >>>> From: Iuliana Prodan <iuliana.prodan at nxp.com>
> >>>>
> >>>> Add the reserve-memory nodes used by DSP when the rpmsg
> >>>> feature is enabled.
> >>>> These can be later used in a dsp node, like:
> >>>> dsp: dsp at 3b6e8000 {
> >>>>    compatible = "fsl,imx8mp-dsp";
> >>>>    reg = <0x3b6e8000 0x88000>;
> >>>>    mbox-names = "tx0", "rx0", "rxdb0";
> >>>>    mboxes = <&mu2 2 0>, <&mu2 2 1>,
> >>>>            <&mu2 3 0>, <&mu2 3 1>;
> >>>>    memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
> >>>>            <&dsp_vdev0vring1>, <&dsp_reserved>;
> >>>>    status = "okay";
> >>> Drop this example from commit msg, useless and not really correct.
> >> Ok, will drop it. But this is a correct example, is just incomplete.
> > No, status=okay is redundant, thus it is not a correct example.
> ok
> >>>> };
> >>>>
> >>>> Signed-off-by: Iuliana Prodan <iuliana.prodan at nxp.com>
> >>>> ---
> >>>>    arch/arm64/boot/dts/freescale/imx8mp.dtsi | 12 ++++++++++++
> >>>>    1 file changed, 12 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> index cc406bb338fe..eedc1921af62 100644
> >>>> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> @@ -210,6 +210,18 @@
> >>>>                    dsp_reserved: dsp at 92400000 {
> >>>>                            reg = <0 0x92400000 0 0x2000000>;
> >>>>                            no-map;
> >>> Please test the patches before sending. This does not build.
> >> I've tested on remoteproc tree, but it seems I missed a bracket when
> >> sending upstream. Sorry abut this, will fix it in v2.
> > No, this is not how testing works. You must test this patch. This means
> > you tested something, then ported patch to entirely different tree,
> > resolved conflicts in buggy way and send it without testing. Nope.
> >
> >> Should I test this on other tree(s)?
> > You test the patch on the tree you send it. What is the point to test it
> > on some old code, cherry-pick with bugs and then send?
> >
> > If you have cross-tree dependencies between subsystem, isn't linux-next
> > for this?

linux-next tree is the tree we want.