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>, <jm@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 v10 03/33] remoteproc: k3-r5: Refactor sequential core power up/down operations
Date: Thu, 17 Apr 2025 23:49:31 +0530 [thread overview]
Message-ID: <20250417182001.3903905-4-b-padhi@ti.com> (raw)
In-Reply-To: <20250417182001.3903905-1-b-padhi@ti.com>
The existing implementation of the waiting mechanism in
"k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to
be set as part of the firmware boot process in "k3_r5_rproc_start()".
The "k3_r5_cluster_rproc_init()" function is invoked in the probe
routine which causes unexpected failures in cases where the firmware is
unavailable at boot time, resulting in probe failure and removal of the
remoteproc handles in the sysfs paths.
To address this, the waiting mechanism is refactored out of the probe
routine into the appropriate "k3_r5_rproc_{prepare/unprepare}()"
functions. This allows the probe routine to complete without depending
on firmware booting, while still maintaining the required
power-synchronization between cores.
Further, this wait mechanism is dropped from
"k3_r5_rproc_{start/stop}()" functions as they deal with Core Run/Halt
operations, and as such, there is no constraint in Running or Halting
the cores of a cluster in order.
Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1")
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v10: Changelog:
1. Re-ordered this patch from [v9 08/26] to [v10 03/33].
Link to v9:
https://lore.kernel.org/all/20250317120622.1746415-9-b-padhi@ti.com/
drivers/remoteproc/ti_k3_r5_remoteproc.c | 110 +++++++++++++----------
1 file changed, 63 insertions(+), 47 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 3fc0b97dec600..ba082ca13e750 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -440,13 +440,36 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
- struct k3_r5_core *core = kproc->core;
+ struct k3_r5_core *core = kproc->core, *core0, *core1;
struct device *dev = kproc->dev;
u32 ctrl = 0, cfg = 0, stat = 0;
u64 boot_vec = 0;
bool mem_init_dis;
int ret;
+ /*
+ * R5 cores require to be powered on sequentially, core0 should be in
+ * higher power state than core1 in a cluster. So, wait for core0 to
+ * power up before proceeding to core1 and put timeout of 2sec. This
+ * waiting mechanism is necessary because rproc_auto_boot_callback() for
+ * core1 can be called before core0 due to thread execution order.
+ *
+ * By placing the wait mechanism here in .prepare() ops, this condition
+ * is enforced for rproc boot requests from sysfs as well.
+ */
+ core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
+ core1 = list_last_entry(&cluster->cores, struct k3_r5_core, elem);
+ if (cluster->mode == CLUSTER_MODE_SPLIT && core == core1 &&
+ !core0->released_from_reset) {
+ ret = wait_event_interruptible_timeout(cluster->core_transition,
+ core0->released_from_reset,
+ msecs_to_jiffies(2000));
+ if (ret <= 0) {
+ dev_err(dev, "can not power up core1 before core0");
+ return -EPERM;
+ }
+ }
+
ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
if (ret < 0)
return ret;
@@ -462,6 +485,14 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
return ret;
}
+ /*
+ * Notify all threads in the wait queue when core0 state has changed so
+ * that threads waiting for this condition can be executed.
+ */
+ core->released_from_reset = true;
+ if (core == core0)
+ wake_up_interruptible(&cluster->core_transition);
+
/*
* Newer IP revisions like on J7200 SoCs support h/w auto-initialization
* of TCMs, so there is no need to perform the s/w memzero. This bit is
@@ -507,10 +538,30 @@ static int k3_r5_rproc_unprepare(struct rproc *rproc)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
- struct k3_r5_core *core = kproc->core;
+ struct k3_r5_core *core = kproc->core, *core0, *core1;
struct device *dev = kproc->dev;
int ret;
+ /*
+ * Ensure power-down of cores is sequential in split mode. Core1 must
+ * power down before Core0 to maintain the expected state. By placing
+ * the wait mechanism here in .unprepare() ops, this condition is
+ * enforced for rproc stop or shutdown requests from sysfs and device
+ * removal as well.
+ */
+ core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
+ core1 = list_last_entry(&cluster->cores, struct k3_r5_core, elem);
+ if (cluster->mode == CLUSTER_MODE_SPLIT && core == core0 &&
+ core1->released_from_reset) {
+ ret = wait_event_interruptible_timeout(cluster->core_transition,
+ !core1->released_from_reset,
+ msecs_to_jiffies(2000));
+ if (ret <= 0) {
+ dev_err(dev, "can not power down core0 before core1");
+ return -EPERM;
+ }
+ }
+
/* Re-use LockStep-mode reset logic for Single-CPU mode */
ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
cluster->mode == CLUSTER_MODE_SINGLECPU) ?
@@ -518,6 +569,14 @@ static int k3_r5_rproc_unprepare(struct rproc *rproc)
if (ret)
dev_err(dev, "unable to disable cores, ret = %d\n", ret);
+ /*
+ * Notify all threads in the wait queue when core1 state has changed so
+ * that threads waiting for this condition can be executed.
+ */
+ core->released_from_reset = false;
+ if (core == core1)
+ wake_up_interruptible(&cluster->core_transition);
+
return ret;
}
@@ -543,7 +602,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
struct device *dev = kproc->dev;
- struct k3_r5_core *core0, *core;
+ struct k3_r5_core *core;
u32 boot_addr;
int ret;
@@ -565,21 +624,9 @@ static int k3_r5_rproc_start(struct rproc *rproc)
goto unroll_core_run;
}
} else {
- /* do not allow core 1 to start before core 0 */
- core0 = list_first_entry(&cluster->cores, struct k3_r5_core,
- elem);
- if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
- dev_err(dev, "%s: can not start core 1 before core 0\n",
- __func__);
- return -EPERM;
- }
-
ret = k3_r5_core_run(core);
if (ret)
return ret;
-
- core->released_from_reset = true;
- wake_up_interruptible(&cluster->core_transition);
}
return 0;
@@ -620,8 +667,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
- struct device *dev = kproc->dev;
- struct k3_r5_core *core1, *core = kproc->core;
+ struct k3_r5_core *core = kproc->core;
int ret;
/* halt all applicable cores */
@@ -634,16 +680,6 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
}
}
} else {
- /* do not allow core 0 to stop before core 1 */
- core1 = list_last_entry(&cluster->cores, struct k3_r5_core,
- elem);
- if (core != core1 && core1->rproc->state != RPROC_OFFLINE) {
- dev_err(dev, "%s: can not stop core 0 before core 1\n",
- __func__);
- ret = -EPERM;
- goto out;
- }
-
ret = k3_r5_core_halt(core);
if (ret)
goto out;
@@ -1271,26 +1307,6 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
cluster->mode == CLUSTER_MODE_SINGLECPU ||
cluster->mode == CLUSTER_MODE_SINGLECORE)
break;
-
- /*
- * R5 cores require to be powered on sequentially, core0
- * should be in higher power state than core1 in a cluster
- * So, wait for current core to power up before proceeding
- * to next core and put timeout of 2sec for each core.
- *
- * This waiting mechanism is necessary because
- * rproc_auto_boot_callback() for core1 can be called before
- * core0 due to thread execution order.
- */
- ret = wait_event_interruptible_timeout(cluster->core_transition,
- core->released_from_reset,
- msecs_to_jiffies(2000));
- if (ret <= 0) {
- dev_err(dev,
- "Timed out waiting for %s core to power up!\n",
- rproc->name);
- goto out;
- }
}
return 0;
--
2.34.1
next prev parent reply other threads:[~2025-04-17 18:20 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:19 [PATCH v10 00/33] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 01/33] remoteproc: k3-r5: Drop check performed in k3_r5_rproc_{mbox_callback/kick} Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 02/33] remoteproc: k3-dsp: Drop check performed in k3_dsp_rproc_{mbox_callback/kick} Beleswar Padhi
2025-04-17 18:19 ` Beleswar Padhi [this message]
2025-04-17 18:19 ` [PATCH v10 04/33] remoteproc: k3-r5: Re-order internal memory initialization functions Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 05/33] remoteproc: k3-r5: Re-order k3_r5_release_tsp() function Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 06/33] remoteproc: k3-r5: Refactor Data Structures to Align with DSP and M4 Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 07/33] remoteproc: k3-r5: Use k3_r5_rproc_mem_data structure for memory info Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 08/33] remoteproc: k3-{m4/dsp}: Add a void ptr member in rproc internal struct Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 09/33] remoteproc: k3-m4: Add pointer to rproc struct within k3_m4_rproc Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 10/33] remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 11/33] remoteproc: k3: Refactor shared data structures Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 12/33] remoteproc: k3: Refactor mailbox rx_callback functions into common driver Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 13/33] remoteproc: k3: Refactor .kick rproc ops " Beleswar Padhi
2025-04-21 14:58 ` Andrew Davis
2025-04-22 5:55 ` Beleswar Prasad Padhi
2025-04-17 18:19 ` [PATCH v10 14/33] remoteproc: k3-dsp: Correct Reset logic for devices without lresets Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 15/33] remoteproc: k3: Refactor rproc_reset() implementation into common driver Beleswar Padhi
2025-04-21 14:42 ` Andrew Davis
2025-04-22 5:53 ` Beleswar Prasad Padhi
2025-04-22 14:21 ` Andrew Davis
2025-04-23 8:24 ` Beleswar Prasad Padhi
2025-04-17 18:19 ` [PATCH v10 16/33] remoteproc: k3-dsp: Correct Reset deassert logic for devices w/o lresets Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 17/33] remoteproc: k3: Refactor rproc_release() implementation into common driver Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 18/33] remoteproc: k3-m4: Ping the mbox while acquiring the channel Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 19/33] remoteproc: k3: Refactor rproc_request_mbox() implementations into common driver Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 20/33] remoteproc: k3-dsp: Don't override rproc ops in IPC-only mode Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 21/33] remoteproc: k3-dsp: Assert local reset during .prepare callback Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 22/33] remoteproc: k3: Refactor .prepare rproc ops into common driver Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 23/33] remoteproc: k3: Refactor .unprepare " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 24/33] remoteproc: k3: Refactor .start " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 25/33] remoteproc: k3: Refactor .stop " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 26/33] remoteproc: k3: Refactor .attach " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 27/33] remoteproc: k3: Refactor .detach " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 28/33] remoteproc: k3: Refactor .get_loaded_rsc_table " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 29/33] remoteproc: k3: Refactor .da_to_va rproc " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 30/33] remoteproc: k3: Refactor of_get_memories() functions " Beleswar Padhi
2025-04-17 18:19 ` [PATCH v10 31/33] remoteproc: k3: Refactor mem_release() " Beleswar Padhi
2025-04-17 18:20 ` [PATCH v10 32/33] remoteproc: k3: Refactor reserved_mem_init() " Beleswar Padhi
2025-04-17 18:20 ` [PATCH v10 33/33] remoteproc: k3: Refactor release_tsp() " Beleswar Padhi
2025-04-23 21:06 ` [PATCH v10 00/33] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Judith Mendez
2025-04-24 3:48 ` Beleswar Prasad Padhi
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=20250417182001.3903905-4-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=jm@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.