On Tue, Sep 12, 2023 at 12:54 PM Iuliana Prodan <iuliana.prodan@xxxxxxx> 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@xxxxxxx> > >>>> > >>>> 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@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@xxxxxxx> > >>>> --- > >>>> 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@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.