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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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.

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.




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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux