On 11/12/25 7:49 AM, Philippe Schenker wrote:
On Tue, 2025-11-11 at 10:11 -0600, Andrew Davis wrote:
On 11/11/25 1:16 AM, Philippe Schenker wrote:
From: Philippe Schenker <[email protected]>
Add is_running callback to query the R5F core halt status via the
TI-SCI processor control API. This allows the remoteproc framework
to determine whether the R5F core is currently runnin.
The core is considered running when the
PROC_BOOT_CTRL_FLAG_R5_CORE_HALT
bit is not set in the control flags.
Signed-off-by: Philippe Schenker <[email protected]>
---
Changes in v3:
- Implemented Andrew's suggestion to assign size before casting for
memory safety.
- Added Anshul's Reviewed-by, thanks!
Changes in v2:
- Made sure there are no build-warnings caused by this series.
drivers/remoteproc/ti_k3_r5f_rproc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
b/drivers/remoteproc/ti_k3_r5f_rproc.c
index c6356729e9db..7326f5a4b30b 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -573,6 +573,22 @@ static void *k3_r5f_da_to_va(struct udevice
*dev, ulong da, ulong size, bool *is
return map_physmem(da, size, MAP_NOCACHE);
}
+static int k3_r5f_is_running(struct udevice *dev)
+{
+ struct k3_r5f_core *core = dev_get_priv(dev);
+ u32 cfg, ctrl, sts;
+ u64 boot_vec;
+ int ret;
+
+ dev_dbg(dev, "%s\n", __func__);
This debug statement doesn't do much other than note when the
function is called, which can be done with other tracing methods.
Either drop it or have it also print something useful like the
status of the core (running / not running).
Hi Andrew, and thanks for also looking at this patch! I actually put
that dev_dbg() there to be in line with all the other functions in this
file. They all have this.
I'll keep it for consistency with the existing functions, but I agree
these could all be cleaned up in a future refactoring patch.
Fair enough
Other than that LGTM,
Reviewed-by: Andrew Davis <[email protected]>
BTW this function would be the same for all the ti_k3_* rproc
drivers, in Linux all these were factored out to common K3 helpers,
might be a good refactor for here in U-Boot also..
Thanks! Good to know, if I touch it again I can refactor those common
functions out like on kernel.
No worries, my comment was more a hint to either Beleswar or Hari,
I'm not expecting you to cleanup our driver for us :)
Andrew
Philippe
+
+ ret = ti_sci_proc_get_status(&core->tsp, &boot_vec, &cfg, &ctrl,
&sts);
+ if (ret)
+ return -1;
+
+ return !!(ctrl & PROC_BOOT_CTRL_FLAG_R5_CORE_HALT);
+}
+
static int k3_r5f_init(struct udevice *dev)
{
return 0;
@@ -590,6 +606,7 @@ static const struct dm_rproc_ops
k3_r5f_rproc_ops = {
.stop = k3_r5f_stop,
.load = k3_r5f_load,
.device_to_virt = k3_r5f_da_to_va,
+ .is_running = k3_r5f_is_running,
};
static int k3_r5f_rproc_configure(struct k3_r5f_core *core)
