All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v5 0/9] remoteproc: Add support for attaching with rproc
@ 2020-07-07 21:00 Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 1/9] remoteproc: Add new RPROC_DETACHED state Mathieu Poirier
                   ` (9 more replies)
  0 siblings, 10 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

This set provides functionality allowing the remoteproc core to attach to 
a remote processor that was started by another entity.

New in V5:
1) Added Bjorn's reviewed-by.
2) Removed PM runtime call from patch 04.
3) Used a 'case' statement in patch 05.

Patches that need to be reviewed: 4, 5 and 9.

Applies cleanly on rproc-next (49cff1256879)

Thanks,
Mathieu

Mathieu Poirier (9):
  remoteproc: Add new RPROC_DETACHED state
  remoteproc: Add new attach() remoteproc operation
  remoteproc: Introducing function rproc_attach()
  remoteproc: Introducing function rproc_actuate()
  remoteproc: Introducing function rproc_validate()
  remoteproc: Refactor function rproc_boot()
  remoteproc: Refactor function rproc_trigger_auto_boot()
  remoteproc: Refactor function rproc_free_vring()
  remoteproc: Properly handle firmware name when attaching

 drivers/remoteproc/remoteproc_core.c     | 213 +++++++++++++++++++++--
 drivers/remoteproc/remoteproc_internal.h |   8 +
 drivers/remoteproc/remoteproc_sysfs.c    |  17 +-
 include/linux/remoteproc.h               |   9 +-
 4 files changed, 230 insertions(+), 17 deletions(-)

-- 
2.25.1


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

* [PATCH v5 1/9] remoteproc: Add new RPROC_DETACHED state
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 2/9] remoteproc: Add new attach() remoteproc operation Mathieu Poirier
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Add a new RPROC_DETACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_sysfs.c | 1 +
 include/linux/remoteproc.h            | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
index 52b871327b55..264759713934 100644
--- a/drivers/remoteproc/remoteproc_sysfs.c
+++ b/drivers/remoteproc/remoteproc_sysfs.c
@@ -72,6 +72,7 @@ static const char * const rproc_state_string[] = {
 	[RPROC_RUNNING]		= "running",
 	[RPROC_CRASHED]		= "crashed",
 	[RPROC_DELETED]		= "deleted",
+	[RPROC_DETACHED]	= "detached",
 	[RPROC_LAST]		= "invalid",
 };
 
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index e7b7bab8b235..21182ad2d059 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -400,6 +400,8 @@ struct rproc_ops {
  * @RPROC_RUNNING:	device is up and running
  * @RPROC_CRASHED:	device has crashed; need to start recovery
  * @RPROC_DELETED:	device is deleted
+ * @RPROC_DETACHED:	device has been booted by another entity and waiting
+ *			for the core to attach to it
  * @RPROC_LAST:		just keep this one at the end
  *
  * Please note that the values of these states are used as indices
@@ -414,7 +416,8 @@ enum rproc_state {
 	RPROC_RUNNING	= 2,
 	RPROC_CRASHED	= 3,
 	RPROC_DELETED	= 4,
-	RPROC_LAST	= 5,
+	RPROC_DETACHED	= 5,
+	RPROC_LAST	= 6,
 };
 
 /**
-- 
2.25.1


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

* [PATCH v5 2/9] remoteproc: Add new attach() remoteproc operation
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 1/9] remoteproc: Add new RPROC_DETACHED state Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 3/9] remoteproc: Introducing function rproc_attach() Mathieu Poirier
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Add an new attach() operation in order to properly deal with
scenarios where the remoteproc core needs to attach to a
remote processor that has been booted by another entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_internal.h | 8 ++++++++
 include/linux/remoteproc.h               | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 4ba7cb59d3e8..fc710866f8ce 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -79,6 +79,14 @@ static inline int rproc_unprepare_device(struct rproc *rproc)
 	return 0;
 }
 
+static inline int rproc_attach_device(struct rproc *rproc)
+{
+	if (rproc->ops->attach)
+		return rproc->ops->attach(rproc);
+
+	return 0;
+}
+
 static inline
 int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
 {
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 21182ad2d059..bf6a310ba870 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -359,6 +359,7 @@ enum rsc_handling_status {
  * @unprepare:	unprepare device after stop
  * @start:	power on the device and boot it
  * @stop:	power off the device
+ * @attach:	attach to a device that his already powered up
  * @kick:	kick a virtqueue (virtqueue id given as a parameter)
  * @da_to_va:	optional platform hook to perform address translations
  * @parse_fw:	parse firmware to extract information (e.g. resource table)
@@ -379,6 +380,7 @@ struct rproc_ops {
 	int (*unprepare)(struct rproc *rproc);
 	int (*start)(struct rproc *rproc);
 	int (*stop)(struct rproc *rproc);
+	int (*attach)(struct rproc *rproc);
 	void (*kick)(struct rproc *rproc, int vqid);
 	void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
 	int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
-- 
2.25.1


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

* [PATCH v5 3/9] remoteproc: Introducing function rproc_attach()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 1/9] remoteproc: Add new RPROC_DETACHED state Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 2/9] remoteproc: Add new attach() remoteproc operation Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate() Mathieu Poirier
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Introducing function rproc_attach() to enact the same actions as
rproc_start(), but without the steps related to the handling of
a firmware image.  That way we can properly deal with scenarios
where the remoteproc core needs to attach with a remote processsor
that has been booted by another entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 42 ++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 0f95e025ba03..1e8e66a25bd6 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1369,6 +1369,48 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
 	return ret;
 }
 
+static int __maybe_unused rproc_attach(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	int ret;
+
+	ret = rproc_prepare_subdevices(rproc);
+	if (ret) {
+		dev_err(dev, "failed to prepare subdevices for %s: %d\n",
+			rproc->name, ret);
+		goto out;
+	}
+
+	/* Attach to the remote processor */
+	ret = rproc_attach_device(rproc);
+	if (ret) {
+		dev_err(dev, "can't attach to rproc %s: %d\n",
+			rproc->name, ret);
+		goto unprepare_subdevices;
+	}
+
+	/* Start any subdevices for the remote processor */
+	ret = rproc_start_subdevices(rproc);
+	if (ret) {
+		dev_err(dev, "failed to probe subdevices for %s: %d\n",
+			rproc->name, ret);
+		goto stop_rproc;
+	}
+
+	rproc->state = RPROC_RUNNING;
+
+	dev_info(dev, "remote processor %s is now attached\n", rproc->name);
+
+	return 0;
+
+stop_rproc:
+	rproc->ops->stop(rproc);
+unprepare_subdevices:
+	rproc_unprepare_subdevices(rproc);
+out:
+	return ret;
+}
+
 /*
  * take a firmware and boot a remote processor with it.
  */
-- 
2.25.1


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

* [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (2 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 3/9] remoteproc: Introducing function rproc_attach() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-09  8:29   ` Arnaud POULIQUEN
  2020-07-07 21:00 ` [PATCH v5 5/9] remoteproc: Introducing function rproc_validate() Mathieu Poirier
                   ` (5 subsequent siblings)
  9 siblings, 1 reply; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Introduce function rproc_actuate() that provides the same
functionatlity as rproc_fw_boot(), but without the steps that
involve interaction with the firmware image.  That way we can
deal with scenarios where the remoteproc core is attaching
to a remote processor that has already been started by another
entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 59 +++++++++++++++++++++++++++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 1e8e66a25bd6..fd424662801f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1369,7 +1369,7 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
 	return ret;
 }
 
-static int __maybe_unused rproc_attach(struct rproc *rproc)
+static int rproc_attach(struct rproc *rproc)
 {
 	struct device *dev = &rproc->dev;
 	int ret;
@@ -1490,6 +1490,63 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
 	return ret;
 }
 
+/*
+ * Attach to remote processor - similar to rproc_fw_boot() but without
+ * the steps that deal with the firmware image.
+ */
+static int __maybe_unused rproc_actuate(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	int ret;
+
+	/*
+	 * if enabling an IOMMU isn't relevant for this rproc, this is
+	 * just a nop
+	 */
+	ret = rproc_enable_iommu(rproc);
+	if (ret) {
+		dev_err(dev, "can't enable iommu: %d\n", ret);
+		return ret;
+	}
+
+	/* reset max_notifyid */
+	rproc->max_notifyid = -1;
+
+	/* reset handled vdev */
+	rproc->nb_vdev = 0;
+
+	/*
+	 * Handle firmware resources required to attach to a remote processor.
+	 * Because we are attaching rather than booting the remote processor,
+	 * we expect the platform driver to properly set rproc->table_ptr.
+	 */
+	ret = rproc_handle_resources(rproc, rproc_loading_handlers);
+	if (ret) {
+		dev_err(dev, "Failed to process resources: %d\n", ret);
+		goto disable_iommu;
+	}
+
+	/* Allocate carveout resources associated to rproc */
+	ret = rproc_alloc_registered_carveouts(rproc);
+	if (ret) {
+		dev_err(dev, "Failed to allocate associated carveouts: %d\n",
+			ret);
+		goto clean_up_resources;
+	}
+
+	ret = rproc_attach(rproc);
+	if (ret)
+		goto clean_up_resources;
+
+	return 0;
+
+clean_up_resources:
+	rproc_resource_cleanup(rproc);
+disable_iommu:
+	rproc_disable_iommu(rproc);
+	return ret;
+}
+
 /*
  * take a firmware and boot it up.
  *
-- 
2.25.1


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

* [PATCH v5 5/9] remoteproc: Introducing function rproc_validate()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (3 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-09  8:32   ` Arnaud POULIQUEN
  2020-07-07 21:00 ` [PATCH v5 6/9] remoteproc: Refactor function rproc_boot() Mathieu Poirier
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Add a new function to assert the general health of the remote
processor before handing it to the remoteproc core.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 41 ++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index fd424662801f..ad500c291d5f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2040,6 +2040,43 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
 #endif
 EXPORT_SYMBOL(rproc_get_by_phandle);
 
+static int rproc_validate(struct rproc *rproc)
+{
+	switch (rproc->state) {
+	case RPROC_OFFLINE:
+		/*
+		 * An offline processor without a start()
+		 * function makes no sense.
+		 */
+		if (!rproc->ops->start)
+			return -EINVAL;
+		break;
+	case RPROC_DETACHED:
+		/*
+		 * A remote processor in a detached state without an
+		 * attach() function makes not sense.
+		 */
+		if (!rproc->ops->attach)
+			return -EINVAL;
+		/*
+		 * When attaching to a remote processor the device memory
+		 * is already available and as such there is no need to have a
+		 * cached table.
+		 */
+		if (rproc->cached_table)
+			return -EINVAL;
+		break;
+	default:
+		/*
+		 * When adding a remote processor, the state of the device
+		 * can be offline or detached, nothing else.
+		 */
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 /**
  * rproc_add() - register a remote processor
  * @rproc: the remote processor handle to register
@@ -2069,6 +2106,10 @@ int rproc_add(struct rproc *rproc)
 	if (ret < 0)
 		return ret;
 
+	ret = rproc_validate(rproc);
+	if (ret < 0)
+		return ret;
+
 	dev_info(dev, "%s is available\n", rproc->name);
 
 	/* create debugfs entries */
-- 
2.25.1


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

* [PATCH v5 6/9] remoteproc: Refactor function rproc_boot()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (4 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 5/9] remoteproc: Introducing function rproc_validate() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 7/9] remoteproc: Refactor function rproc_trigger_auto_boot() Mathieu Poirier
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Refactor function rproc_boot() to properly deal with scenarios
where the remoteproc core needs to attach with a remote
processor that has already been booted by an external entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index ad500c291d5f..caea920ce4b8 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1494,7 +1494,7 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
  * Attach to remote processor - similar to rproc_fw_boot() but without
  * the steps that deal with the firmware image.
  */
-static int __maybe_unused rproc_actuate(struct rproc *rproc)
+static int rproc_actuate(struct rproc *rproc)
 {
 	struct device *dev = &rproc->dev;
 	int ret;
@@ -1905,24 +1905,30 @@ int rproc_boot(struct rproc *rproc)
 		goto unlock_mutex;
 	}
 
-	/* skip the boot process if rproc is already powered up */
+	/* skip the boot or attach process if rproc is already powered up */
 	if (atomic_inc_return(&rproc->power) > 1) {
 		ret = 0;
 		goto unlock_mutex;
 	}
 
-	dev_info(dev, "powering up %s\n", rproc->name);
+	if (rproc->state == RPROC_DETACHED) {
+		dev_info(dev, "attaching to %s\n", rproc->name);
 
-	/* load firmware */
-	ret = request_firmware(&firmware_p, rproc->firmware, dev);
-	if (ret < 0) {
-		dev_err(dev, "request_firmware failed: %d\n", ret);
-		goto downref_rproc;
-	}
+		ret = rproc_actuate(rproc);
+	} else {
+		dev_info(dev, "powering up %s\n", rproc->name);
 
-	ret = rproc_fw_boot(rproc, firmware_p);
+		/* load firmware */
+		ret = request_firmware(&firmware_p, rproc->firmware, dev);
+		if (ret < 0) {
+			dev_err(dev, "request_firmware failed: %d\n", ret);
+			goto downref_rproc;
+		}
 
-	release_firmware(firmware_p);
+		ret = rproc_fw_boot(rproc, firmware_p);
+
+		release_firmware(firmware_p);
+	}
 
 downref_rproc:
 	if (ret)
-- 
2.25.1


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

* [PATCH v5 7/9] remoteproc: Refactor function rproc_trigger_auto_boot()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (5 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 6/9] remoteproc: Refactor function rproc_boot() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 8/9] remoteproc: Refactor function rproc_free_vring() Mathieu Poirier
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Refactor function rproc_trigger_auto_boot() to properly deal
with scenarios where the remoteproc core needs to attach with a
remote processor that has already been booted by an external
entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index caea920ce4b8..08de81828e4e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1568,6 +1568,15 @@ static int rproc_trigger_auto_boot(struct rproc *rproc)
 {
 	int ret;
 
+	/*
+	 * Since the remote processor is in a detached state, it has already
+	 * been booted by another entity.  As such there is no point in waiting
+	 * for a firmware image to be loaded, we can simply initiate the process
+	 * of attaching to it immediately.
+	 */
+	if (rproc->state == RPROC_DETACHED)
+		return rproc_boot(rproc);
+
 	/*
 	 * We're initiating an asynchronous firmware loading, so we can
 	 * be built-in kernel code, without hanging the boot process.
-- 
2.25.1


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

* [PATCH v5 8/9] remoteproc: Refactor function rproc_free_vring()
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (6 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 7/9] remoteproc: Refactor function rproc_trigger_auto_boot() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-07 21:00 ` [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching Mathieu Poirier
  2020-07-09 16:23 ` [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Arnaud POULIQUEN
  9 siblings, 0 replies; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

When function rproc_free_vring() clears the virtio device section
it does so on the cached resource table rather than the one
installed in the remote processor memory.  When a remote processor
has been booted by another entity there is no need to use a cached
table and as such, no need to clear the virtio device section in
it.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 08de81828e4e..6b6e4ec8cf3a 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -410,10 +410,22 @@ void rproc_free_vring(struct rproc_vring *rvring)
 
 	idr_remove(&rproc->notifyids, rvring->notifyid);
 
-	/* reset resource entry info */
-	rsc = (void *)rproc->table_ptr + rvring->rvdev->rsc_offset;
-	rsc->vring[idx].da = 0;
-	rsc->vring[idx].notifyid = -1;
+	/*
+	 * At this point rproc_stop() has been called and the installed resource
+	 * table in the remote processor memory may no longer be accessible. As
+	 * such and as per rproc_stop(), rproc->table_ptr points to the cached
+	 * resource table (rproc->cached_table).  The cached resource table is
+	 * only available when a remote processor has been booted by the
+	 * remoteproc core, otherwise it is NULL.
+	 *
+	 * Based on the above, reset the virtio device section in the cached
+	 * resource table only if there is one to work with.
+	 */
+	if (rproc->table_ptr) {
+		rsc = (void *)rproc->table_ptr + rvring->rvdev->rsc_offset;
+		rsc->vring[idx].da = 0;
+		rsc->vring[idx].notifyid = -1;
+	}
 }
 
 static int rproc_vdev_do_start(struct rproc_subdev *subdev)
-- 
2.25.1


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

* [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (7 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 8/9] remoteproc: Refactor function rproc_free_vring() Mathieu Poirier
@ 2020-07-07 21:00 ` Mathieu Poirier
  2020-07-09  8:58   ` Arnaud POULIQUEN
  2020-07-09 16:23 ` [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Arnaud POULIQUEN
  9 siblings, 1 reply; 14+ messages in thread
From: Mathieu Poirier @ 2020-07-07 21:00 UTC (permalink / raw)
  To: ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

This patch prevents the firmware image name from being displayed when
the remoteproc core is attaching to a remote processor. This is needed
needed since there is no guarantee about the nature of the firmware
image that is loaded by the external entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 drivers/remoteproc/remoteproc_core.c  | 18 ++++++++++++++++++
 drivers/remoteproc/remoteproc_sysfs.c | 16 ++++++++++++++--
 include/linux/remoteproc.h            |  2 ++
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 6b6e4ec8cf3a..099c76ab198f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1624,6 +1624,14 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
 
 	rproc->state = RPROC_OFFLINE;
 
+	/*
+	 * The remote processor has been stopped and is now offline, which means
+	 * that the next time it is brought back online the remoteproc core will
+	 * be responsible to load its firmware.  As such it is no longer
+	 * autonomous.
+	 */
+	rproc->autonomous = false;
+
 	dev_info(dev, "stopped remote processor %s\n", rproc->name);
 
 	return 0;
@@ -2142,6 +2150,16 @@ int rproc_add(struct rproc *rproc)
 	/* create debugfs entries */
 	rproc_create_debug_dir(rproc);
 
+	/*
+	 * Remind ourselves the remote processor has been attached to rather
+	 * than booted by the remoteproc core.  This is important because the
+	 * RPROC_DETACHED state will be lost as soon as the remote processor
+	 * has been attached to.  Used in firmware_show() and reset in
+	 * rproc_stop().
+	 */
+	if (rproc->state == RPROC_DETACHED)
+		rproc->autonomous = true;
+
 	/* if rproc is marked always-on, request it to boot */
 	if (rproc->auto_boot) {
 		ret = rproc_trigger_auto_boot(rproc);
diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
index 264759713934..eea514cec50e 100644
--- a/drivers/remoteproc/remoteproc_sysfs.c
+++ b/drivers/remoteproc/remoteproc_sysfs.c
@@ -15,8 +15,20 @@ static ssize_t firmware_show(struct device *dev, struct device_attribute *attr,
 			  char *buf)
 {
 	struct rproc *rproc = to_rproc(dev);
-
-	return sprintf(buf, "%s\n", rproc->firmware);
+	const char *firmware = rproc->firmware;
+
+	/*
+	 * If the remote processor has been started by an external
+	 * entity we have no idea of what image it is running.  As such
+	 * simply display a generic string rather then rproc->firmware.
+	 *
+	 * Here we rely on the autonomous flag because a remote processor
+	 * may have been attached to and currently in a running state.
+	 */
+	if (rproc->autonomous)
+		firmware = "unknown";
+
+	return sprintf(buf, "%s\n", firmware);
 }
 
 /* Change firmware name via sysfs */
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index bf6a310ba870..cf5e31556780 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -491,6 +491,7 @@ struct rproc_dump_segment {
  * @table_sz: size of @cached_table
  * @has_iommu: flag to indicate if remote processor is behind an MMU
  * @auto_boot: flag to indicate if remote processor should be auto-started
+ * @autonomous: true if an external entity has booted the remote processor
  * @dump_segments: list of segments in the firmware
  * @nb_vdev: number of vdev currently handled by rproc
  */
@@ -524,6 +525,7 @@ struct rproc {
 	size_t table_sz;
 	bool has_iommu;
 	bool auto_boot;
+	bool autonomous;
 	struct list_head dump_segments;
 	int nb_vdev;
 	u8 elf_class;
-- 
2.25.1


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

* Re: [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate()
  2020-07-07 21:00 ` [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate() Mathieu Poirier
@ 2020-07-09  8:29   ` Arnaud POULIQUEN
  0 siblings, 0 replies; 14+ messages in thread
From: Arnaud POULIQUEN @ 2020-07-09  8:29 UTC (permalink / raw)
  To: Mathieu Poirier, ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Hi Mathieu,


On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> Introduce function rproc_actuate() that provides the same
> functionatlity as rproc_fw_boot(), but without the steps that
> involve interaction with the firmware image.  That way we can
> deal with scenarios where the remoteproc core is attaching
> to a remote processor that has already been started by another
> entity.
> 
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

Thanks,
Arnaud
> ---
>  drivers/remoteproc/remoteproc_core.c | 59 +++++++++++++++++++++++++++-
>  1 file changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 1e8e66a25bd6..fd424662801f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1369,7 +1369,7 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
>  	return ret;
>  }
>  
> -static int __maybe_unused rproc_attach(struct rproc *rproc)
> +static int rproc_attach(struct rproc *rproc)
>  {
>  	struct device *dev = &rproc->dev;
>  	int ret;
> @@ -1490,6 +1490,63 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
>  	return ret;
>  }
>  
> +/*
> + * Attach to remote processor - similar to rproc_fw_boot() but without
> + * the steps that deal with the firmware image.
> + */
> +static int __maybe_unused rproc_actuate(struct rproc *rproc)
> +{
> +	struct device *dev = &rproc->dev;
> +	int ret;
> +
> +	/*
> +	 * if enabling an IOMMU isn't relevant for this rproc, this is
> +	 * just a nop
> +	 */
> +	ret = rproc_enable_iommu(rproc);
> +	if (ret) {
> +		dev_err(dev, "can't enable iommu: %d\n", ret);
> +		return ret;
> +	}
> +
> +	/* reset max_notifyid */
> +	rproc->max_notifyid = -1;
> +
> +	/* reset handled vdev */
> +	rproc->nb_vdev = 0;
> +
> +	/*
> +	 * Handle firmware resources required to attach to a remote processor.
> +	 * Because we are attaching rather than booting the remote processor,
> +	 * we expect the platform driver to properly set rproc->table_ptr.
> +	 */
> +	ret = rproc_handle_resources(rproc, rproc_loading_handlers);
> +	if (ret) {
> +		dev_err(dev, "Failed to process resources: %d\n", ret);
> +		goto disable_iommu;
> +	}
> +
> +	/* Allocate carveout resources associated to rproc */
> +	ret = rproc_alloc_registered_carveouts(rproc);
> +	if (ret) {
> +		dev_err(dev, "Failed to allocate associated carveouts: %d\n",
> +			ret);
> +		goto clean_up_resources;
> +	}
> +
> +	ret = rproc_attach(rproc);
> +	if (ret)
> +		goto clean_up_resources;
> +
> +	return 0;
> +
> +clean_up_resources:
> +	rproc_resource_cleanup(rproc);
> +disable_iommu:
> +	rproc_disable_iommu(rproc);
> +	return ret;
> +}
> +
>  /*
>   * take a firmware and boot it up.
>   *
> 

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

* Re: [PATCH v5 5/9] remoteproc: Introducing function rproc_validate()
  2020-07-07 21:00 ` [PATCH v5 5/9] remoteproc: Introducing function rproc_validate() Mathieu Poirier
@ 2020-07-09  8:32   ` Arnaud POULIQUEN
  0 siblings, 0 replies; 14+ messages in thread
From: Arnaud POULIQUEN @ 2020-07-09  8:32 UTC (permalink / raw)
  To: Mathieu Poirier, ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel



On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> Add a new function to assert the general health of the remote
> processor before handing it to the remoteproc core.
> 
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

Thanks,
Arnaud

> ---
>  drivers/remoteproc/remoteproc_core.c | 41 ++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index fd424662801f..ad500c291d5f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2040,6 +2040,43 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
>  #endif
>  EXPORT_SYMBOL(rproc_get_by_phandle);
>  
> +static int rproc_validate(struct rproc *rproc)
> +{
> +	switch (rproc->state) {
> +	case RPROC_OFFLINE:
> +		/*
> +		 * An offline processor without a start()
> +		 * function makes no sense.
> +		 */
> +		if (!rproc->ops->start)
> +			return -EINVAL;
> +		break;
> +	case RPROC_DETACHED:
> +		/*
> +		 * A remote processor in a detached state without an
> +		 * attach() function makes not sense.
> +		 */
> +		if (!rproc->ops->attach)
> +			return -EINVAL;
> +		/*
> +		 * When attaching to a remote processor the device memory
> +		 * is already available and as such there is no need to have a
> +		 * cached table.
> +		 */
> +		if (rproc->cached_table)
> +			return -EINVAL;
> +		break;
> +	default:
> +		/*
> +		 * When adding a remote processor, the state of the device
> +		 * can be offline or detached, nothing else.
> +		 */
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  /**
>   * rproc_add() - register a remote processor
>   * @rproc: the remote processor handle to register
> @@ -2069,6 +2106,10 @@ int rproc_add(struct rproc *rproc)
>  	if (ret < 0)
>  		return ret;
>  
> +	ret = rproc_validate(rproc);
> +	if (ret < 0)
> +		return ret;
> +
>  	dev_info(dev, "%s is available\n", rproc->name);
>  
>  	/* create debugfs entries */
> 

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

* Re: [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching
  2020-07-07 21:00 ` [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching Mathieu Poirier
@ 2020-07-09  8:58   ` Arnaud POULIQUEN
  0 siblings, 0 replies; 14+ messages in thread
From: Arnaud POULIQUEN @ 2020-07-09  8:58 UTC (permalink / raw)
  To: Mathieu Poirier, ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel



On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> This patch prevents the firmware image name from being displayed when
> the remoteproc core is attaching to a remote processor. This is needed
> needed since there is no guarantee about the nature of the firmware
> image that is loaded by the external entity.
> 
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

Thanks,
Arnaud

> ---
>  drivers/remoteproc/remoteproc_core.c  | 18 ++++++++++++++++++
>  drivers/remoteproc/remoteproc_sysfs.c | 16 ++++++++++++++--
>  include/linux/remoteproc.h            |  2 ++
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 6b6e4ec8cf3a..099c76ab198f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1624,6 +1624,14 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
>  
>  	rproc->state = RPROC_OFFLINE;
>  
> +	/*
> +	 * The remote processor has been stopped and is now offline, which means
> +	 * that the next time it is brought back online the remoteproc core will
> +	 * be responsible to load its firmware.  As such it is no longer
> +	 * autonomous.
> +	 */
> +	rproc->autonomous = false;
> +
>  	dev_info(dev, "stopped remote processor %s\n", rproc->name);
>  
>  	return 0;
> @@ -2142,6 +2150,16 @@ int rproc_add(struct rproc *rproc)
>  	/* create debugfs entries */
>  	rproc_create_debug_dir(rproc);
>  
> +	/*
> +	 * Remind ourselves the remote processor has been attached to rather
> +	 * than booted by the remoteproc core.  This is important because the
> +	 * RPROC_DETACHED state will be lost as soon as the remote processor
> +	 * has been attached to.  Used in firmware_show() and reset in
> +	 * rproc_stop().
> +	 */
> +	if (rproc->state == RPROC_DETACHED)
> +		rproc->autonomous = true;
> +
>  	/* if rproc is marked always-on, request it to boot */
>  	if (rproc->auto_boot) {
>  		ret = rproc_trigger_auto_boot(rproc);
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> index 264759713934..eea514cec50e 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -15,8 +15,20 @@ static ssize_t firmware_show(struct device *dev, struct device_attribute *attr,
>  			  char *buf)
>  {
>  	struct rproc *rproc = to_rproc(dev);
> -
> -	return sprintf(buf, "%s\n", rproc->firmware);
> +	const char *firmware = rproc->firmware;
> +
> +	/*
> +	 * If the remote processor has been started by an external
> +	 * entity we have no idea of what image it is running.  As such
> +	 * simply display a generic string rather then rproc->firmware.
> +	 *
> +	 * Here we rely on the autonomous flag because a remote processor
> +	 * may have been attached to and currently in a running state.
> +	 */
> +	if (rproc->autonomous)
> +		firmware = "unknown";
> +
> +	return sprintf(buf, "%s\n", firmware);
>  }
>  
>  /* Change firmware name via sysfs */
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index bf6a310ba870..cf5e31556780 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -491,6 +491,7 @@ struct rproc_dump_segment {
>   * @table_sz: size of @cached_table
>   * @has_iommu: flag to indicate if remote processor is behind an MMU
>   * @auto_boot: flag to indicate if remote processor should be auto-started
> + * @autonomous: true if an external entity has booted the remote processor
>   * @dump_segments: list of segments in the firmware
>   * @nb_vdev: number of vdev currently handled by rproc
>   */
> @@ -524,6 +525,7 @@ struct rproc {
>  	size_t table_sz;
>  	bool has_iommu;
>  	bool auto_boot;
> +	bool autonomous;
>  	struct list_head dump_segments;
>  	int nb_vdev;
>  	u8 elf_class;
> 

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

* Re: [PATCH v5 0/9] remoteproc: Add support for attaching with rproc
  2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
                   ` (8 preceding siblings ...)
  2020-07-07 21:00 ` [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching Mathieu Poirier
@ 2020-07-09 16:23 ` Arnaud POULIQUEN
  9 siblings, 0 replies; 14+ messages in thread
From: Arnaud POULIQUEN @ 2020-07-09 16:23 UTC (permalink / raw)
  To: Mathieu Poirier, ohad, bjorn.andersson; +Cc: linux-remoteproc, linux-kernel

Hi Mathieu

On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> This set provides functionality allowing the remoteproc core to attach to 
> a remote processor that was started by another entity.
> 
> New in V5:
> 1) Added Bjorn's reviewed-by.
> 2) Removed PM runtime call from patch 04.
> 3) Used a 'case' statement in patch 05.
> 
> Patches that need to be reviewed: 4, 5 and 9.
> 
> Applies cleanly on rproc-next (49cff1256879)

I tested the series in different modes, no issue observed.
Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

Thanks for your work!

Arnaud

> 
> Thanks,
> Mathieu
> 
> Mathieu Poirier (9):
>   remoteproc: Add new RPROC_DETACHED state
>   remoteproc: Add new attach() remoteproc operation
>   remoteproc: Introducing function rproc_attach()
>   remoteproc: Introducing function rproc_actuate()
>   remoteproc: Introducing function rproc_validate()
>   remoteproc: Refactor function rproc_boot()
>   remoteproc: Refactor function rproc_trigger_auto_boot()
>   remoteproc: Refactor function rproc_free_vring()
>   remoteproc: Properly handle firmware name when attaching
> 
>  drivers/remoteproc/remoteproc_core.c     | 213 +++++++++++++++++++++--
>  drivers/remoteproc/remoteproc_internal.h |   8 +
>  drivers/remoteproc/remoteproc_sysfs.c    |  17 +-
>  include/linux/remoteproc.h               |   9 +-
>  4 files changed, 230 insertions(+), 17 deletions(-)
> 

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

end of thread, other threads:[~2020-07-09 16:23 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-07 21:00 [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 1/9] remoteproc: Add new RPROC_DETACHED state Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 2/9] remoteproc: Add new attach() remoteproc operation Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 3/9] remoteproc: Introducing function rproc_attach() Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate() Mathieu Poirier
2020-07-09  8:29   ` Arnaud POULIQUEN
2020-07-07 21:00 ` [PATCH v5 5/9] remoteproc: Introducing function rproc_validate() Mathieu Poirier
2020-07-09  8:32   ` Arnaud POULIQUEN
2020-07-07 21:00 ` [PATCH v5 6/9] remoteproc: Refactor function rproc_boot() Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 7/9] remoteproc: Refactor function rproc_trigger_auto_boot() Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 8/9] remoteproc: Refactor function rproc_free_vring() Mathieu Poirier
2020-07-07 21:00 ` [PATCH v5 9/9] remoteproc: Properly handle firmware name when attaching Mathieu Poirier
2020-07-09  8:58   ` Arnaud POULIQUEN
2020-07-09 16:23 ` [PATCH v5 0/9] remoteproc: Add support for attaching with rproc Arnaud POULIQUEN

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.