2024-02-16 23:30:34

by noman pouigt

[permalink] [raw]
Subject: Audio dsp recovery using remoteproc

mailbox to dsp_1 is currently modeling platform pcm driver.
mailbox to dsp_2 is also doing the same.

Platform driver callbacks cause IPC to be sent to dsp's.
Lifecycle of two dsp's are managed by separate remoteproc
drivers. Single sound card is exposed.

Separate watchdog interrupts from the corresponding dsp's
are connected to remoteproc to manage crashing of the
individual dsp's. How can I restart both the dsp when either
of them crashes using the kernel device model? Remoteproc
driver currently only restarts the crashed dsp instead of restarting
both the dsp. It is needed to bring up the hardware in a consistent
state as both the dsp's are connected to a common hardware.

I thought of making a virtual parent remoteproc device
and then managing individual dsp as a subdevice of that parent device
but remoteproc device node is associated with the individual elf file i.e.
it can manage only a single dsp.

How can I model remoteproc drivers using linux device model so that when either
of them crashes both the dsp's get reloaded by the remoteproc framework.

MailBox ---- DSP_1 ---
| |
Linux ------ common_hw -> speaker/mic
| |
MailBox ---- DSP_2 ---


2024-02-27 17:16:02

by Mathieu Poirier

[permalink] [raw]
Subject: Re: Audio dsp recovery using remoteproc

Good day,

On Fri, Feb 16, 2024 at 03:29:56PM -0800, noman pouigt wrote:
> mailbox to dsp_1 is currently modeling platform pcm driver.
> mailbox to dsp_2 is also doing the same.
>
> Platform driver callbacks cause IPC to be sent to dsp's.
> Lifecycle of two dsp's are managed by separate remoteproc
> drivers. Single sound card is exposed.
>
> Separate watchdog interrupts from the corresponding dsp's
> are connected to remoteproc to manage crashing of the
> individual dsp's. How can I restart both the dsp when either
> of them crashes using the kernel device model? Remoteproc
> driver currently only restarts the crashed dsp instead of restarting
> both the dsp. It is needed to bring up the hardware in a consistent
> state as both the dsp's are connected to a common hardware.
>

Ok

> I thought of making a virtual parent remoteproc device
> and then managing individual dsp as a subdevice of that parent device
> but remoteproc device node is associated with the individual elf file i.e.
> it can manage only a single dsp.

You are on the right track but perhaps not fully aware of what is already done
for multi core remote processors. I suggest you have a thorough look at TI's
K3R5 driver[1] and one of it's DTB[2]. In the DTB each remote processor loads a
different firmware file, which seems to be what you are looking for.

Thanks,
Mathieu

[1]. https://elixir.bootlin.com/linux/v6.8-rc6/source/drivers/remoteproc/ti_k3_r5_remoteproc.c
[2]. https://elixir.bootlin.com/linux/v6.8-rc6/source/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi#L397


>
> How can I model remoteproc drivers using linux device model so that when either
> of them crashes both the dsp's get reloaded by the remoteproc framework.
>
> MailBox ---- DSP_1 ---
> | |
> Linux ------ common_hw -> speaker/mic
> | |
> MailBox ---- DSP_2 ---
>