From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: noman pouigt <variksla@gmail.com>
Cc: linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org
Subject: Re: Audio dsp recovery using remoteproc
Date: Tue, 27 Feb 2024 10:08:27 -0700 [thread overview]
Message-ID: <Zd4XCwOeJ+exUjN0@p14s> (raw)
In-Reply-To: <CAES_P+_0tWVtn+tyUi1TvkWi4rA-ZBj8e7_pnJd1h_J3S3Cn8Q@mail.gmail.com>
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 ---
>
prev parent reply other threads:[~2024-02-27 17:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 23:29 Audio dsp recovery using remoteproc noman pouigt
2024-02-27 17:08 ` Mathieu Poirier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zd4XCwOeJ+exUjN0@p14s \
--to=mathieu.poirier@linaro.org \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=variksla@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).