[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250108063727.1416324-1-b-padhi@ti.com>
Date: Wed, 8 Jan 2025 12:07:24 +0530
From: Beleswar Padhi <b-padhi@...com>
To: <andersson@...nel.org>, <mathieu.poirier@...aro.org>
CC: <afd@...com>, <hnagalla@...com>, <u-kumar1@...com>, <s-vadapalli@...com>,
<srk@...com>, <jan.kiszka@...mens.com>,
<christophe.jaillet@...adoo.fr>, <jkangas@...hat.com>,
<eballetbo@...hat.com>, <b-padhi@...com>,
<linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH v2 0/3] Rework TI K3 R5F remoteproc driver
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 is also posted[1]
which deals 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 have excluded R5F driver from the common
refactoring in the final series[1].
NOTE:
This series is _dependent_ upon the below series which does devm_ cleanup
[Now merged in rproc-next/linux-next].
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 (j7*) devices.
2. Tested Lockstep, Split and Single-CPU Mode configuration (wherever
applicable) of R5F remoteprocs in all Jacinto K3 (j7*) 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[2].
v2: Changelog:
1. Changed variable name "is_attach_ongoing" to "is_attached" in PATCH #1 and
PATCH #2. [Udit]
2. Triggered wakeup event signal only for core0 in .prepare(), and only for
core1 in .unprepare() in PATCH #3. [Udit]
3. Carried Reviewed-by tags from v1 of the series.
Link to v1:
https://lore.kernel.org/all/20241224091457.1050233-1-b-padhi@ti.com/
Thanks,
Beleswar
[0]: https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/
[1]: https://lore.kernel.org/all/20250103101231.1508151-1-b-padhi@ti.com/
[2]: 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 | 63 ++++++--
drivers/remoteproc/ti_k3_r5_remoteproc.c | 179 ++++++++++++++--------
2 files changed, 161 insertions(+), 81 deletions(-)
--
2.34.1
Powered by blists - more mailing lists