[PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Iuliana Prodan (OSS)]

From: Iuliana Prodan <iuliana.prodan@nxp.com>

Add the .find_loaded_rsc_table operation for i.MX DSP.
We need it for inter-process communication between DSP
and main core.

This callback is used to find the resource table (defined
in remote processor linker script) where the address of the
vrings along with the other allocated resources (carveouts etc)
are stored.
If this is not found, the vrings are not allocated and
the IPC between cores will not work.

Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
---
 drivers/remoteproc/imx_dsp_rproc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index d95fa5586189..b5634507d953 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
 	.kick		= imx_dsp_rproc_kick,
 	.load		= imx_dsp_rproc_elf_load_segments,
 	.parse_fw	= imx_dsp_rproc_parse_fw,
+	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
 	.sanity_check	= rproc_elf_sanity_check,
 	.get_boot_addr	= rproc_elf_get_boot_addr,
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Daniel Baluta]

On Thu, Jul 13, 2023 at 2:13 AM Iuliana Prodan (OSS)
<iuliana.prodan@oss.nxp.com> wrote:
>
> From: Iuliana Prodan <iuliana.prodan@nxp.com>
>
> Add the .find_loaded_rsc_table operation for i.MX DSP.
> We need it for inter-process communication between DSP
> and main core.
>
> This callback is used to find the resource table (defined
> in remote processor linker script) where the address of the
> vrings along with the other allocated resources (carveouts etc)
> are stored.
> If this is not found, the vrings are not allocated and
> the IPC between cores will not work.
>
> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Mathieu Poirier]

On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan <iuliana.prodan@nxp.com>
> 
> Add the .find_loaded_rsc_table operation for i.MX DSP.
> We need it for inter-process communication between DSP
> and main core.
> 
> This callback is used to find the resource table (defined
> in remote processor linker script) where the address of the
> vrings along with the other allocated resources (carveouts etc)
> are stored.
> If this is not found, the vrings are not allocated and
> the IPC between cores will not work.

Is there a constraint on the system memory the M4 can address?  If so there
will be a need to declare address ranges for vrings and buffers in reserved
memory in the DT.

Thanks,
Mathieu

> 
> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
> ---
>  drivers/remoteproc/imx_dsp_rproc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> index d95fa5586189..b5634507d953 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
> @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
>  	.kick		= imx_dsp_rproc_kick,
>  	.load		= imx_dsp_rproc_elf_load_segments,
>  	.parse_fw	= imx_dsp_rproc_parse_fw,
> +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
>  	.sanity_check	= rproc_elf_sanity_check,
>  	.get_boot_addr	= rproc_elf_get_boot_addr,
>  };
> -- 
> 2.17.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Iuliana Prodan]

On 7/17/2023 8:42 PM, Mathieu Poirier wrote:
> On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
>> From: Iuliana Prodan <iuliana.prodan@nxp.com>
>>
>> Add the .find_loaded_rsc_table operation for i.MX DSP.
>> We need it for inter-process communication between DSP
>> and main core.
>>
>> This callback is used to find the resource table (defined
>> in remote processor linker script) where the address of the
>> vrings along with the other allocated resources (carveouts etc)
>> are stored.
>> If this is not found, the vrings are not allocated and
>> the IPC between cores will not work.
> Is there a constraint on the system memory the M4 can address?  If so there
> will be a need to declare address ranges for vrings and buffers in reserved
> memory in the DT.
>
> Thanks,
> Mathieu

Hi Mathieu,

No, there is no constraint on memory.

We want the Cortex A core to communicate with the HiFi4 DSP.
The Cortex A is in charge of starting the DSP and loading the firmware 
in HiFi4's memory.
When using rpmsg for IPC, the Cortex A needs to find the resource table 
(defined in the DSP linker script) and this is done using 
.find_loaded_rsc_table callback.

For the DT, we are using a (not upstream) device tree where we have the 
reserved-memory for dsp_vdev0vring0, dsp_vdev0vring1 and dsp_vdev0buffer.

Iulia


>> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
>> ---
>>   drivers/remoteproc/imx_dsp_rproc.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
>> index d95fa5586189..b5634507d953 100644
>> --- a/drivers/remoteproc/imx_dsp_rproc.c
>> +++ b/drivers/remoteproc/imx_dsp_rproc.c
>> @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
>>   	.kick		= imx_dsp_rproc_kick,
>>   	.load		= imx_dsp_rproc_elf_load_segments,
>>   	.parse_fw	= imx_dsp_rproc_parse_fw,
>> +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
>>   	.sanity_check	= rproc_elf_sanity_check,
>>   	.get_boot_addr	= rproc_elf_get_boot_addr,
>>   };
>> -- 
>> 2.17.1
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Mathieu Poirier]

On Tue, Jul 18, 2023 at 11:25:03AM +0300, Iuliana Prodan wrote:
> On 7/17/2023 8:42 PM, Mathieu Poirier wrote:
> > On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
> > > From: Iuliana Prodan <iuliana.prodan@nxp.com>
> > > 
> > > Add the .find_loaded_rsc_table operation for i.MX DSP.
> > > We need it for inter-process communication between DSP
> > > and main core.
> > > 
> > > This callback is used to find the resource table (defined
> > > in remote processor linker script) where the address of the
> > > vrings along with the other allocated resources (carveouts etc)
> > > are stored.
> > > If this is not found, the vrings are not allocated and
> > > the IPC between cores will not work.
> > Is there a constraint on the system memory the M4 can address?  If so there
> > will be a need to declare address ranges for vrings and buffers in reserved
> > memory in the DT.
> > 
> > Thanks,
> > Mathieu
> 
> Hi Mathieu,
> 
> No, there is no constraint on memory.
> 
> We want the Cortex A core to communicate with the HiFi4 DSP.
> The Cortex A is in charge of starting the DSP and loading the firmware in
> HiFi4's memory.
> When using rpmsg for IPC, the Cortex A needs to find the resource table
> (defined in the DSP linker script) and this is done using
> .find_loaded_rsc_table callback.
> 
> For the DT, we are using a (not upstream) device tree where we have the
> reserved-memory for dsp_vdev0vring0, dsp_vdev0vring1 and dsp_vdev0buffer.

That is the part I'm interested in.  Don't we need the reserved-memory entries?
Otherwise the M4 may not be able to access the memory chosen by the application
processor, most likely leading to a crash.

> 
> Iulia
> 
> 
> > > Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
> > > ---
> > >   drivers/remoteproc/imx_dsp_rproc.c | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> > > index d95fa5586189..b5634507d953 100644
> > > --- a/drivers/remoteproc/imx_dsp_rproc.c
> > > +++ b/drivers/remoteproc/imx_dsp_rproc.c
> > > @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
> > >   	.kick		= imx_dsp_rproc_kick,
> > >   	.load		= imx_dsp_rproc_elf_load_segments,
> > >   	.parse_fw	= imx_dsp_rproc_parse_fw,
> > > +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> > >   	.sanity_check	= rproc_elf_sanity_check,
> > >   	.get_boot_addr	= rproc_elf_get_boot_addr,
> > >   };
> > > -- 
> > > 2.17.1
> > > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Iuliana Prodan]

On 7/18/2023 6:23 PM, Mathieu Poirier wrote:
> On Tue, Jul 18, 2023 at 11:25:03AM +0300, Iuliana Prodan wrote:
>> On 7/17/2023 8:42 PM, Mathieu Poirier wrote:
>>> On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
>>>> From: Iuliana Prodan <iuliana.prodan@nxp.com>
>>>>
>>>> Add the .find_loaded_rsc_table operation for i.MX DSP.
>>>> We need it for inter-process communication between DSP
>>>> and main core.
>>>>
>>>> This callback is used to find the resource table (defined
>>>> in remote processor linker script) where the address of the
>>>> vrings along with the other allocated resources (carveouts etc)
>>>> are stored.
>>>> If this is not found, the vrings are not allocated and
>>>> the IPC between cores will not work.
>>> Is there a constraint on the system memory the M4 can address?  If so there
>>> will be a need to declare address ranges for vrings and buffers in reserved
>>> memory in the DT.
>>>
>>> Thanks,
>>> Mathieu
>> Hi Mathieu,
>>
>> No, there is no constraint on memory.
>>
>> We want the Cortex A core to communicate with the HiFi4 DSP.
>> The Cortex A is in charge of starting the DSP and loading the firmware in
>> HiFi4's memory.
>> When using rpmsg for IPC, the Cortex A needs to find the resource table
>> (defined in the DSP linker script) and this is done using
>> .find_loaded_rsc_table callback.
>>
>> For the DT, we are using a (not upstream) device tree where we have the
>> reserved-memory for dsp_vdev0vring0, dsp_vdev0vring1 and dsp_vdev0buffer.
> That is the part I'm interested in.  Don't we need the reserved-memory entries?
> Otherwise the M4 may not be able to access the memory chosen by the application
> processor, most likely leading to a crash.

This kernel module (imx_dsp_rproc) is used only for DSP.
For M4 core we use imx_rproc.

Iulia

>> Iulia
>>
>>
>>>> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
>>>> ---
>>>>    drivers/remoteproc/imx_dsp_rproc.c | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
>>>> index d95fa5586189..b5634507d953 100644
>>>> --- a/drivers/remoteproc/imx_dsp_rproc.c
>>>> +++ b/drivers/remoteproc/imx_dsp_rproc.c
>>>> @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
>>>>    	.kick		= imx_dsp_rproc_kick,
>>>>    	.load		= imx_dsp_rproc_elf_load_segments,
>>>>    	.parse_fw	= imx_dsp_rproc_parse_fw,
>>>> +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
>>>>    	.sanity_check	= rproc_elf_sanity_check,
>>>>    	.get_boot_addr	= rproc_elf_get_boot_addr,
>>>>    };
>>>> -- 
>>>> 2.17.1
>>>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Mathieu Poirier]

On Tue, Jul 18, 2023 at 06:40:53PM +0300, Iuliana Prodan wrote:
> 
> On 7/18/2023 6:23 PM, Mathieu Poirier wrote:
> > On Tue, Jul 18, 2023 at 11:25:03AM +0300, Iuliana Prodan wrote:
> > > On 7/17/2023 8:42 PM, Mathieu Poirier wrote:
> > > > On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
> > > > > From: Iuliana Prodan <iuliana.prodan@nxp.com>
> > > > > 
> > > > > Add the .find_loaded_rsc_table operation for i.MX DSP.
> > > > > We need it for inter-process communication between DSP
> > > > > and main core.
> > > > > 
> > > > > This callback is used to find the resource table (defined
> > > > > in remote processor linker script) where the address of the
> > > > > vrings along with the other allocated resources (carveouts etc)
> > > > > are stored.
> > > > > If this is not found, the vrings are not allocated and
> > > > > the IPC between cores will not work.
> > > > Is there a constraint on the system memory the M4 can address?  If so there
> > > > will be a need to declare address ranges for vrings and buffers in reserved
> > > > memory in the DT.
> > > > 
> > > > Thanks,
> > > > Mathieu
> > > Hi Mathieu,
> > > 
> > > No, there is no constraint on memory.
> > > 
> > > We want the Cortex A core to communicate with the HiFi4 DSP.
> > > The Cortex A is in charge of starting the DSP and loading the firmware in
> > > HiFi4's memory.
> > > When using rpmsg for IPC, the Cortex A needs to find the resource table
> > > (defined in the DSP linker script) and this is done using
> > > .find_loaded_rsc_table callback.
> > > 
> > > For the DT, we are using a (not upstream) device tree where we have the
> > > reserved-memory for dsp_vdev0vring0, dsp_vdev0vring1 and dsp_vdev0buffer.
> > That is the part I'm interested in.  Don't we need the reserved-memory entries?
> > Otherwise the M4 may not be able to access the memory chosen by the application
> > processor, most likely leading to a crash.
> 
> This kernel module (imx_dsp_rproc) is used only for DSP.
> For M4 core we use imx_rproc.
>

The point here is that if I merge this patch and someone tries to load a
firmware image that has a resource table, the system will likely crash because
reserved memories haven't been specified in the DT.

Unless there is a very good reason not to, I would like to see the companion DT
changes submitted with this patch so that the feature is complete.

> Iulia
> 
> > > Iulia
> > > 
> > > 
> > > > > Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
> > > > > ---
> > > > >    drivers/remoteproc/imx_dsp_rproc.c | 1 +
> > > > >    1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> > > > > index d95fa5586189..b5634507d953 100644
> > > > > --- a/drivers/remoteproc/imx_dsp_rproc.c
> > > > > +++ b/drivers/remoteproc/imx_dsp_rproc.c
> > > > > @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
> > > > >    	.kick		= imx_dsp_rproc_kick,
> > > > >    	.load		= imx_dsp_rproc_elf_load_segments,
> > > > >    	.parse_fw	= imx_dsp_rproc_parse_fw,
> > > > > +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> > > > >    	.sanity_check	= rproc_elf_sanity_check,
> > > > >    	.get_boot_addr	= rproc_elf_get_boot_addr,
> > > > >    };
> > > > > -- 
> > > > > 2.17.1
> > > > > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Iuliana Prodan]

On 9/5/2023 12:16 AM, Mathieu Poirier wrote:
> On Tue, Jul 18, 2023 at 06:40:53PM +0300, Iuliana Prodan wrote:
>> On 7/18/2023 6:23 PM, Mathieu Poirier wrote:
>>> On Tue, Jul 18, 2023 at 11:25:03AM +0300, Iuliana Prodan wrote:
>>>> On 7/17/2023 8:42 PM, Mathieu Poirier wrote:
>>>>> On Thu, Jul 13, 2023 at 01:42:20AM +0300, Iuliana Prodan (OSS) wrote:
>>>>>> From: Iuliana Prodan <iuliana.prodan@nxp.com>
>>>>>>
>>>>>> Add the .find_loaded_rsc_table operation for i.MX DSP.
>>>>>> We need it for inter-process communication between DSP
>>>>>> and main core.
>>>>>>
>>>>>> This callback is used to find the resource table (defined
>>>>>> in remote processor linker script) where the address of the
>>>>>> vrings along with the other allocated resources (carveouts etc)
>>>>>> are stored.
>>>>>> If this is not found, the vrings are not allocated and
>>>>>> the IPC between cores will not work.
>>>>> Is there a constraint on the system memory the M4 can address?  If so there
>>>>> will be a need to declare address ranges for vrings and buffers in reserved
>>>>> memory in the DT.
>>>>>
>>>>> Thanks,
>>>>> Mathieu
>>>> Hi Mathieu,
>>>>
>>>> No, there is no constraint on memory.
>>>>
>>>> We want the Cortex A core to communicate with the HiFi4 DSP.
>>>> The Cortex A is in charge of starting the DSP and loading the firmware in
>>>> HiFi4's memory.
>>>> When using rpmsg for IPC, the Cortex A needs to find the resource table
>>>> (defined in the DSP linker script) and this is done using
>>>> .find_loaded_rsc_table callback.
>>>>
>>>> For the DT, we are using a (not upstream) device tree where we have the
>>>> reserved-memory for dsp_vdev0vring0, dsp_vdev0vring1 and dsp_vdev0buffer.
>>> That is the part I'm interested in.  Don't we need the reserved-memory entries?
>>> Otherwise the M4 may not be able to access the memory chosen by the application
>>> processor, most likely leading to a crash.
>> This kernel module (imx_dsp_rproc) is used only for DSP.
>> For M4 core we use imx_rproc.
>>
> The point here is that if I merge this patch and someone tries to load a
> firmware image that has a resource table, the system will likely crash because
> reserved memories haven't been specified in the DT.
>
> Unless there is a very good reason not to, I would like to see the companion DT
> changes submitted with this patch so that the feature is complete.
TBH, so far, I haven't realized that those reserved-memory nodes are not 
upstream
I see they are, as examples, in fsl,dsp.yaml [1]

Let me check why is that and I'll get back - hope, with the DT changes.

[1] 
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml#L170

>> Iulia
>>
>>>> Iulia
>>>>
>>>>
>>>>>> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
>>>>>> ---
>>>>>>     drivers/remoteproc/imx_dsp_rproc.c | 1 +
>>>>>>     1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
>>>>>> index d95fa5586189..b5634507d953 100644
>>>>>> --- a/drivers/remoteproc/imx_dsp_rproc.c
>>>>>> +++ b/drivers/remoteproc/imx_dsp_rproc.c
>>>>>> @@ -941,6 +941,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
>>>>>>     	.kick		= imx_dsp_rproc_kick,
>>>>>>     	.load		= imx_dsp_rproc_elf_load_segments,
>>>>>>     	.parse_fw	= imx_dsp_rproc_parse_fw,
>>>>>> +	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
>>>>>>     	.sanity_check	= rproc_elf_sanity_check,
>>>>>>     	.get_boot_addr	= rproc_elf_get_boot_addr,
>>>>>>     };
>>>>>> -- 
>>>>>> 2.17.1
>>>>>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] Rpmsg support for i.MX DSP with resource table

[Iuliana Prodan (OSS)]

From: Iuliana Prodan <iuliana.prodan@nxp.com>

These patches are needed in order to support rpmsg on DSP when a
resource table is available.

Iuliana Prodan (2):
  remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op
  arm64: dts: imx8mp: add reserve-memory nodes for DSP

 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 12 ++++++++++++
 drivers/remoteproc/imx_dsp_rproc.c        |  1 +
 2 files changed, 13 insertions(+)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op

[Iuliana Prodan (OSS)]

From: Iuliana Prodan <iuliana.prodan@nxp.com>

Add the .find_loaded_rsc_table operation for i.MX DSP.
We need it for inter-process communication between DSP
and main core.

This callback is used to find the resource table (defined
in remote processor linker script) where the address of the
vrings along with the other allocated resources (carveouts etc)
are stored.
If this is not found, the vrings are not allocated and
the IPC between cores will not work.

Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
---
 drivers/remoteproc/imx_dsp_rproc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 8fcda9b74545..a1c62d15f16c 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -940,6 +940,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
 	.kick		= imx_dsp_rproc_kick,
 	.load		= imx_dsp_rproc_elf_load_segments,
 	.parse_fw	= imx_dsp_rproc_parse_fw,
+	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
 	.sanity_check	= rproc_elf_sanity_check,
 	.get_boot_addr	= rproc_elf_get_boot_addr,
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Iuliana Prodan (OSS)]

From: Iuliana Prodan <iuliana.prodan@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@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";
};

Signed-off-by: Iuliana Prodan <iuliana.prodan@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@92400000 {
 			reg = <0 0x92400000 0 0x2000000>;
 			no-map;
+		dsp_vdev0vring0: vdev0vring0@942f0000 {
+			reg = <0 0x942f0000 0 0x8000>;
+			no-map;
+		};
+		dsp_vdev0vring1: vdev0vring1@942f8000 {
+			reg = <0 0x942f8000 0 0x8000>;
+			no-map;
+		};
+		dsp_vdev0buffer: vdev0buffer@94300000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x94300000 0 0x100000>;
+			no-map;
 		};
 	};
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Krzysztof Kozlowski]

On 12/09/2023 00:44, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan <iuliana.prodan@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@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.

> };
> 
> Signed-off-by: Iuliana Prodan <iuliana.prodan@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@92400000 {
>  			reg = <0 0x92400000 0 0x2000000>;
>  			no-map;

Please test the patches before sending. This does not build.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Iuliana Prodan]

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@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@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.
>> };
>>
>> Signed-off-by: Iuliana Prodan <iuliana.prodan@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@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.

Should I test this on other tree(s)?

Thanks,
Iulia

> Best regards,
> Krzysztof
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Krzysztof Kozlowski]

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@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@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.

>>> };
>>>
>>> Signed-off-by: Iuliana Prodan <iuliana.prodan@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@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?


Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Iuliana Prodan]

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@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@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@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@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?

TBH, I don't know, that's why I asked.

For sure one patch is for remoteproc.
For the other, I don't know who will pick it, but I'll tested on 
linux-next, as you suggested.

Thanks,
Iulia

>
> Best regards,
> Krzysztof
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Krzysztof Kozlowski]

On 12/09/2023 10:49, Iuliana Prodan wrote:
>>> 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?
> 
> TBH, I don't know, that's why I asked.
> 
> For sure one patch is for remoteproc.
> For the other, I don't know who will pick it, but I'll tested on 
> linux-next, as you suggested.

MAINTAINERS file (and get_maintainers.pl) will tell you. Specifically,
this does not look really related to remoteproc patch, so it should not
be together in one patchset.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Iuliana Prodan]

On 9/12/2023 12:36 PM, Krzysztof Kozlowski wrote:
> On 12/09/2023 10:49, Iuliana Prodan wrote:
>>>> 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?
>> TBH, I don't know, that's why I asked.
>>
>> For sure one patch is for remoteproc.
>> For the other, I don't know who will pick it, but I'll tested on
>> linux-next, as you suggested.
> MAINTAINERS file (and get_maintainers.pl) will tell you. Specifically,
> this does not look really related to remoteproc patch, so it should not
> be together in one patchset.

Hi Mathieu,

I need to send a v2 - to fix the dtsi missing bracket on patch 2.
So, should I keep the 2 patches together or send them separately?

Thanks,
Iulia




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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@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@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@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@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@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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marco Felsch]

Hi Iuliana,

On 23-09-12, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan <iuliana.prodan@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@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";
> };
> 
> Signed-off-by: Iuliana Prodan <iuliana.prodan@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@92400000 {
>  			reg = <0 0x92400000 0 0x2000000>;
>  			no-map;

This seems broken.

Regards,
  Marco

> +		dsp_vdev0vring0: vdev0vring0@942f0000 {
> +			reg = <0 0x942f0000 0 0x8000>;
> +			no-map;
> +		};
> +		dsp_vdev0vring1: vdev0vring1@942f8000 {
> +			reg = <0 0x942f8000 0 0x8000>;
> +			no-map;
> +		};
> +		dsp_vdev0buffer: vdev0buffer@94300000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x94300000 0 0x100000>;
> +			no-map;
>  		};
>  	};
>  
> -- 
> 2.17.1
> 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Iuliana Prodan]

On 9/12/2023 2:30 PM, Marco Felsch wrote:
> Hi Iuliana,
>
> On 23-09-12, Iuliana Prodan (OSS) wrote:
>> From: Iuliana Prodan <iuliana.prodan@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@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";
>> };
>>
>> Signed-off-by: Iuliana Prodan <iuliana.prodan@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@92400000 {
>>   			reg = <0 0x92400000 0 0x2000000>;
>>   			no-map;
> This seems broken.


You're right.
Already answered to this here: 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2558691.html

Thanks,
Iulia

> Regards,
>    Marco
>
>> +		dsp_vdev0vring0: vdev0vring0@942f0000 {
>> +			reg = <0 0x942f0000 0 0x8000>;
>> +			no-map;
>> +		};
>> +		dsp_vdev0vring1: vdev0vring1@942f8000 {
>> +			reg = <0 0x942f8000 0 0x8000>;
>> +			no-map;
>> +		};
>> +		dsp_vdev0buffer: vdev0buffer@94300000 {
>> +			compatible = "shared-dma-pool";
>> +			reg = <0 0x94300000 0 0x100000>;
>> +			no-map;
>>   		};
>>   	};
>>   
>> -- 
>> 2.17.1
>>
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marco Felsch]

On 23-09-12, Iuliana Prodan wrote:
> On 9/12/2023 2:30 PM, Marco Felsch wrote:
> > Hi Iuliana,
> > 
> > On 23-09-12, Iuliana Prodan (OSS) wrote:
> > > From: Iuliana Prodan <iuliana.prodan@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@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";
> > > };
> > > 
> > > Signed-off-by: Iuliana Prodan <iuliana.prodan@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@92400000 {
> > >   			reg = <0 0x92400000 0 0x2000000>;
> > >   			no-map;
> > This seems broken.
> 
> 
> You're right.
> Already answered to this here:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2558691.html

Sorry, saw it to late..

Regards,
  Marco

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mathieu Poirier]

On Tue, Sep 12, 2023 at 01:51:42PM +0300, Iuliana Prodan wrote:
> On 9/12/2023 12:36 PM, Krzysztof Kozlowski wrote:
> > On 12/09/2023 10:49, Iuliana Prodan wrote:
> > > > > 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?
> > > TBH, I don't know, that's why I asked.
> > > 
> > > For sure one patch is for remoteproc.
> > > For the other, I don't know who will pick it, but I'll tested on
> > > linux-next, as you suggested.
> > MAINTAINERS file (and get_maintainers.pl) will tell you. Specifically,
> > this does not look really related to remoteproc patch, so it should not
> > be together in one patchset.
> 
> Hi Mathieu,
> 
> I need to send a v2 - to fix the dtsi missing bracket on patch 2.
> So, should I keep the 2 patches together or send them separately?
>

Marco is already aware of this patchset so I would keep them together.

> Thanks,
> Iulia
> 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel