linux-remoteproc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1
@ 2024-04-30 10:53 Beleswar Padhi
  2024-04-30 10:53 ` [PATCH v3 1/2] " Beleswar Padhi
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Beleswar Padhi @ 2024-04-30 10:53 UTC (permalink / raw)
  To: andersson
  Cc: mathieu.poirier, s-anna, linux-remoteproc, linux-kernel,
	u-kumar1, nm, devarsht, hnagalla

PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.

Make the powering up of cores sequential, by waiting for the current core
to power-up before proceeding to the next core, with a timeout of 2sec.
Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait
for the current core to be released from reset before proceeding with the
next core.

Also, ensure that core1 can not be powered on before core0 when starting
cores from sysfs. Similarly, ensure that core0 can not be shutdown
before core1 from sysfs.

v3: Changelog:
1) Added my own Signed-off-by in PATCH 1, specifying the changes done
2) Addressed changes requested by adding comments in code in PATCH 1

Link to v2:
https://lore.kernel.org/all/20240424130504.494916-1-b-padhi@ti.com/

v2: Changelog:
1) Fixed multi-line comment format
2) Included root cause of bug in comments
3) Added a patch to ensure power-up/shutdown is sequential via sysfs

Link to v1:
https://lore.kernel.org/all/20230906124756.3480579-1-a-nandan@ti.com/

Apurva Nandan (1):
  remoteproc: k3-r5: Wait for core0 power-up before powering up core1

Beleswar Padhi (1):
  remoteproc: k3-r5: Do not allow core1 to power up before core0 via
    sysfs

 drivers/remoteproc/ti_k3_r5_remoteproc.c | 56 +++++++++++++++++++++++-
 1 file changed, 54 insertions(+), 2 deletions(-)

-- 
2.34.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v3 1/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1
  2024-04-30 10:53 [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi
@ 2024-04-30 10:53 ` Beleswar Padhi
  2024-04-30 10:53 ` [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs Beleswar Padhi
  2024-04-30 16:59 ` [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Mathieu Poirier
  2 siblings, 0 replies; 6+ messages in thread
From: Beleswar Padhi @ 2024-04-30 10:53 UTC (permalink / raw)
  To: andersson
  Cc: mathieu.poirier, s-anna, linux-remoteproc, linux-kernel,
	u-kumar1, nm, devarsht, hnagalla

From: Apurva Nandan <a-nandan@ti.com>

PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.

Make the powering up of cores sequential, by waiting for the current core
to power-up before proceeding to the next core, with a timeout of 2sec.
Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait
for the current core to be released from reset before proceeding with the
next core.

Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")

Signed-off-by: Apurva Nandan <a-nandan@ti.com>
[added comments and fixed code style]
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
 drivers/remoteproc/ti_k3_r5_remoteproc.c | 33 ++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index ad3415a3851b..6d6afd6beb3a 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -103,12 +103,14 @@ struct k3_r5_soc_data {
  * @dev: cached device pointer
  * @mode: Mode to configure the Cluster - Split or LockStep
  * @cores: list of R5 cores within the cluster
+ * @core_transition: wait queue to sync core state changes
  * @soc_data: SoC-specific feature data for a R5FSS
  */
 struct k3_r5_cluster {
 	struct device *dev;
 	enum cluster_mode mode;
 	struct list_head cores;
+	wait_queue_head_t core_transition;
 	const struct k3_r5_soc_data *soc_data;
 };
 
@@ -128,6 +130,7 @@ struct k3_r5_cluster {
  * @atcm_enable: flag to control ATCM enablement
  * @btcm_enable: flag to control BTCM enablement
  * @loczrama: flag to dictate which TCM is at device address 0x0
+ * @released_from_reset: flag to signal when core is out of reset
  */
 struct k3_r5_core {
 	struct list_head elem;
@@ -144,6 +147,7 @@ struct k3_r5_core {
 	u32 atcm_enable;
 	u32 btcm_enable;
 	u32 loczrama;
+	bool released_from_reset;
 };
 
 /**
@@ -460,6 +464,8 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
 			ret);
 		return ret;
 	}
+	core->released_from_reset = true;
+	wake_up_interruptible(&cluster->core_transition);
 
 	/*
 	 * Newer IP revisions like on J7200 SoCs support h/w auto-initialization
@@ -1140,6 +1146,12 @@ static int k3_r5_rproc_configure_mode(struct k3_r5_rproc *kproc)
 		return ret;
 	}
 
+	/*
+	 * Skip the waiting mechanism for sequential power-on of cores if the
+	 * core has already been booted by another entity.
+	 */
+	core->released_from_reset = c_state;
+
 	ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl,
 				     &stat);
 	if (ret < 0) {
@@ -1280,6 +1292,26 @@ 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);
+			return ret;
+		}
 	}
 
 	return 0;
@@ -1709,6 +1741,7 @@ static int k3_r5_probe(struct platform_device *pdev)
 	cluster->dev = dev;
 	cluster->soc_data = data;
 	INIT_LIST_HEAD(&cluster->cores);
+	init_waitqueue_head(&cluster->core_transition);
 
 	ret = of_property_read_u32(np, "ti,cluster-mode", &cluster->mode);
 	if (ret < 0 && ret != -EINVAL) {
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs
  2024-04-30 10:53 [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi
  2024-04-30 10:53 ` [PATCH v3 1/2] " Beleswar Padhi
@ 2024-04-30 10:53 ` Beleswar Padhi
  2024-05-18 10:44   ` Christophe JAILLET
  2024-04-30 16:59 ` [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Mathieu Poirier
  2 siblings, 1 reply; 6+ messages in thread
From: Beleswar Padhi @ 2024-04-30 10:53 UTC (permalink / raw)
  To: andersson
  Cc: mathieu.poirier, s-anna, linux-remoteproc, linux-kernel,
	u-kumar1, nm, devarsht, hnagalla

PSC controller has a limitation that it can only power-up the second
core when the first core is in ON state. Power-state for core0 should be
equal to or higher than core1.

Therefore, prevent core1 from powering up before core0 during the start
process from sysfs. Similarly, prevent core0 from shutting down before
core1 has been shut down from sysfs.

Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
 drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 6d6afd6beb3a..1799b4f6d11e 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -548,7 +548,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 *core;
+	struct k3_r5_core *core0, *core;
 	u32 boot_addr;
 	int ret;
 
@@ -574,6 +574,15 @@ 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)
 			goto put_mbox;
@@ -619,7 +628,8 @@ static int k3_r5_rproc_stop(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 device *dev = kproc->dev;
+	struct k3_r5_core *core1, *core = kproc->core;
 	int ret;
 
 	/* halt all applicable cores */
@@ -632,6 +642,15 @@ 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__);
+			return -EPERM;
+		}
+
 		ret = k3_r5_core_halt(core);
 		if (ret)
 			goto out;
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1
  2024-04-30 10:53 [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi
  2024-04-30 10:53 ` [PATCH v3 1/2] " Beleswar Padhi
  2024-04-30 10:53 ` [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs Beleswar Padhi
@ 2024-04-30 16:59 ` Mathieu Poirier
  2 siblings, 0 replies; 6+ messages in thread
From: Mathieu Poirier @ 2024-04-30 16:59 UTC (permalink / raw)
  To: Beleswar Padhi
  Cc: andersson, s-anna, linux-remoteproc, linux-kernel, u-kumar1, nm,
	devarsht, hnagalla

On Tue, Apr 30, 2024 at 04:23:05PM +0530, Beleswar Padhi wrote:
> PSC controller has a limitation that it can only power-up the second core
> when the first core is in ON state. Power-state for core0 should be equal
> to or higher than core1, else the kernel is seen hanging during rproc
> loading.
> 
> Make the powering up of cores sequential, by waiting for the current core
> to power-up before proceeding to the next core, with a timeout of 2sec.
> Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait
> for the current core to be released from reset before proceeding with the
> next core.
> 
> Also, ensure that core1 can not be powered on before core0 when starting
> cores from sysfs. Similarly, ensure that core0 can not be shutdown
> before core1 from sysfs.
> 
> v3: Changelog:
> 1) Added my own Signed-off-by in PATCH 1, specifying the changes done
> 2) Addressed changes requested by adding comments in code in PATCH 1
> 
> Link to v2:
> https://lore.kernel.org/all/20240424130504.494916-1-b-padhi@ti.com/
> 
> v2: Changelog:
> 1) Fixed multi-line comment format
> 2) Included root cause of bug in comments
> 3) Added a patch to ensure power-up/shutdown is sequential via sysfs
> 
> Link to v1:
> https://lore.kernel.org/all/20230906124756.3480579-1-a-nandan@ti.com/
> 
> Apurva Nandan (1):
>   remoteproc: k3-r5: Wait for core0 power-up before powering up core1
> 
> Beleswar Padhi (1):
>   remoteproc: k3-r5: Do not allow core1 to power up before core0 via
>     sysfs
> 
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 56 +++++++++++++++++++++++-
>  1 file changed, 54 insertions(+), 2 deletions(-)

Applied - thanks,
Mathieu

> 
> -- 
> 2.34.1
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs
  2024-04-30 10:53 ` [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs Beleswar Padhi
@ 2024-05-18 10:44   ` Christophe JAILLET
  2024-05-20 15:14     ` Mathieu Poirier
  0 siblings, 1 reply; 6+ messages in thread
From: Christophe JAILLET @ 2024-05-18 10:44 UTC (permalink / raw)
  To: Beleswar Padhi, andersson
  Cc: mathieu.poirier, s-anna, linux-remoteproc, linux-kernel,
	u-kumar1, nm, devarsht, hnagalla

Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
> PSC controller has a limitation that it can only power-up the second
> core when the first core is in ON state. Power-state for core0 should be
> equal to or higher than core1.
> 
> Therefore, prevent core1 from powering up before core0 during the start
> process from sysfs. Similarly, prevent core0 from shutting down before
> core1 has been shut down from sysfs.
> 
> Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")
> 
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
>   drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +++++++++++++++++++++--
>   1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 6d6afd6beb3a..1799b4f6d11e 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -548,7 +548,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 *core;
> +	struct k3_r5_core *core0, *core;
>   	u32 boot_addr;
>   	int ret;
>   
> @@ -574,6 +574,15 @@ 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)
>   			goto put_mbox;
> @@ -619,7 +628,8 @@ static int k3_r5_rproc_stop(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 device *dev = kproc->dev;
> +	struct k3_r5_core *core1, *core = kproc->core;
>   	int ret;
>   
>   	/* halt all applicable cores */
> @@ -632,6 +642,15 @@ 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__);
> +			return -EPERM;

Hi,

this patch has already reached -next, but should this "return -EPERM;" be :
	ret = -EPERM;
	goto put_mbox;

instead?

CJ

> +		}
> +
>   		ret = k3_r5_core_halt(core);
>   		if (ret)
>   			goto out;


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs
  2024-05-18 10:44   ` Christophe JAILLET
@ 2024-05-20 15:14     ` Mathieu Poirier
  0 siblings, 0 replies; 6+ messages in thread
From: Mathieu Poirier @ 2024-05-20 15:14 UTC (permalink / raw)
  To: Christophe JAILLET
  Cc: Beleswar Padhi, andersson, s-anna, linux-remoteproc,
	linux-kernel, u-kumar1, nm, devarsht, hnagalla

On Sat, 18 May 2024 at 04:44, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
> > PSC controller has a limitation that it can only power-up the second
> > core when the first core is in ON state. Power-state for core0 should be
> > equal to or higher than core1.
> >
> > Therefore, prevent core1 from powering up before core0 during the start
> > process from sysfs. Similarly, prevent core0 from shutting down before
> > core1 has been shut down from sysfs.
> >
> > Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")
> >
> > Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> > ---
> >   drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +++++++++++++++++++++--
> >   1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > index 6d6afd6beb3a..1799b4f6d11e 100644
> > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > @@ -548,7 +548,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 *core;
> > +     struct k3_r5_core *core0, *core;
> >       u32 boot_addr;
> >       int ret;
> >
> > @@ -574,6 +574,15 @@ 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)
> >                       goto put_mbox;
> > @@ -619,7 +628,8 @@ static int k3_r5_rproc_stop(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 device *dev = kproc->dev;
> > +     struct k3_r5_core *core1, *core = kproc->core;
> >       int ret;
> >
> >       /* halt all applicable cores */
> > @@ -632,6 +642,15 @@ 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__);
> > +                     return -EPERM;
>
> Hi,
>
> this patch has already reached -next, but should this "return -EPERM;" be :
>         ret = -EPERM;
>         goto put_mbox;
>
> instead?
>

This has already been addressed:

https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git/commit/?h=rproc-next&id=1dc7242f6ee0c99852cb90676d7fe201cf5de422

> CJ
>
> > +             }
> > +
> >               ret = k3_r5_core_halt(core);
> >               if (ret)
> >                       goto out;
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-05-20 15:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-30 10:53 [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi
2024-04-30 10:53 ` [PATCH v3 1/2] " Beleswar Padhi
2024-04-30 10:53 ` [PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs Beleswar Padhi
2024-05-18 10:44   ` Christophe JAILLET
2024-05-20 15:14     ` Mathieu Poirier
2024-04-30 16:59 ` [PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Mathieu Poirier

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 NNTP newsgroup(s).