From: Beleswar Padhi <b-padhi@ti.com>
To: <andersson@kernel.org>, <mathieu.poirier@linaro.org>
Cc: <afd@ti.com>, <hnagalla@ti.com>, <u-kumar1@ti.com>,
<s-vadapalli@ti.com>, <srk@ti.com>, <jan.kiszka@siemens.com>,
<christophe.jaillet@wanadoo.fr>, <jkangas@redhat.com>,
<eballetbo@redhat.com>, <b-padhi@ti.com>,
<linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] Rework TI K3 R5F remoteproc driver
Date: Tue, 24 Dec 2024 14:44:54 +0530 [thread overview]
Message-ID: <20241224091457.1050233-1-b-padhi@ti.com> (raw)
This series cleans up the TI R5F remoteproc driver by addressing various bugs.
This is also the second series as part of the refactoring of K3 remoteproc
drivers[0]. The third and final series for K3 Refactoring will be posted soon
which will deal with the TI DSP and TI M4 drivers. The R5F driver takes care of
configuring dual core R5Fs in Lockstep/Split mode and therefore has worked out
separate data structures & reset logic than the DSP/M4 drivers which deal with
single core CPUs. Therefore, I wish to exclude R5F driver from the common
refactoring in the upcoming final series.
NOTE:
This series is _dependent_ upon the below series which does devm_ cleanup
https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/
Bugs fixed in this series:
1. Fixed IPC-Only mode attach for R5F cores. PATCH #1
2. Fixed IPC-Only mode attach for DSP cores. (Included in this series, as this
was related to point 1 and fix is similar) PATCH #2
3. Fixed support to load firmware from userspace by refactoring wait mechanism
logic into prepare()/start() ops. PATCH #3
Testing Done:
1. Tested boot of R5F remoteprocs in MCU and MAIN voltage domain in both
IPC-Only mode and Kernel remoteproc mode in all Jacinto K3 devices.
2. Tested Lockstep, Split and Single-CPU Mode configuration (wherever
applicable) of R5F remoteprocs in all Jacinto K3 devices.
3. Tested shutdown of R5F remoteprocs from Linux userspace and also by
executing `modprobe -r ti_k3_r5_remoteproc`.
4. Tested usecases where firmware not available at Kernel boot time, but later
in sysfs, able to load firmware into a remotecore and start it.
5. Tested that each patch in this series generates no new warnings/errors.
Exception: Using the "wait_event_interruptible_timeout" macro in PATCH #3 raises
a -Wshadow warning, which is expected as it is called out in the implementation
of the macro itself[1].
Thanks,
Beleswar
[0]: https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/wait.h#n289
Beleswar Padhi (3):
remoteproc: k3-r5: Fix checks in k3_r5_rproc_{mbox_callback/kick}
remoteproc: k3-dsp: Fix checks in k3_dsp_rproc_{mbox_callback/kick}
remoteproc: k3-r5: Refactor sequential core power up/down operations
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 53 +++++--
drivers/remoteproc/ti_k3_r5_remoteproc.c | 167 +++++++++++++---------
2 files changed, 139 insertions(+), 81 deletions(-)
--
2.34.1
next reply other threads:[~2024-12-24 9:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-24 9:14 Beleswar Padhi [this message]
2024-12-24 9:14 ` [PATCH 1/3] remoteproc: k3-r5: Fix checks in k3_r5_rproc_{mbox_callback/kick} Beleswar Padhi
2024-12-27 14:38 ` Hari Nagalla
2024-12-30 4:06 ` Beleswar Prasad Padhi
2025-01-03 6:05 ` Siddharth Vadapalli
2025-01-03 10:48 ` Kumar, Udit
2025-01-03 10:57 ` Beleswar Prasad Padhi
2025-01-03 13:04 ` Kumar, Udit
2025-01-21 18:47 ` Andrew Davis
2025-01-23 4:43 ` Beleswar Prasad Padhi
2024-12-24 9:14 ` [PATCH 2/3] remoteproc: k3-dsp: Fix checks in k3_dsp_rproc_{mbox_callback/kick} Beleswar Padhi
2025-01-03 6:06 ` Siddharth Vadapalli
2024-12-24 9:14 ` [PATCH v2 3/3] remoteproc: k3-r5: Refactor sequential core power up/down operations Beleswar Padhi
2025-01-03 10:48 ` Kumar, Udit
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=20241224091457.1050233-1-b-padhi@ti.com \
--to=b-padhi@ti.com \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=eballetbo@redhat.com \
--cc=hnagalla@ti.com \
--cc=jan.kiszka@siemens.com \
--cc=jkangas@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=s-vadapalli@ti.com \
--cc=srk@ti.com \
--cc=u-kumar1@ti.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).