From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
Ohad Ben-Cohen <ohad@wizery.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Loic PALLARDY <loic.pallardy@st.com>, Suman Anna <s-anna@ti.com>,
Fabien DESSENNE <fabien.dessenne@st.com>,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v5 1/3] remoteproc: add support for co-processor loaded and booted before kernel
Date: Thu, 13 Feb 2020 18:55:16 -0800 [thread overview]
Message-ID: <20200214025512.GQ1443@yoga> (raw)
In-Reply-To: <20200211174205.22247-2-arnaud.pouliquen@st.com>
On Tue 11 Feb 09:42 PST 2020, Arnaud Pouliquen wrote:
> From: Loic Pallardy <loic.pallardy@st.com>
>
> Remote processor could boot independently or be loaded/started before
> Linux kernel by bootloader or any firmware.
> This patch introduces a new property in rproc core, named skip_fw_load,
> to be able to allocate resources and sub-devices like vdev and to
> synchronize with current state without loading firmware from file system.
This sentence describes the provided patch.
As I expressed in the earlier version, in order to support remoteprocs
that doesn't need firmware loading, e.g. running from some ROM or
dedicated flash storage etc, this patch looks really good.
> It is platform driver responsibility to implement the right firmware
> load ops according to HW specificities.
But this last sentence describes a remoteproc that indeed needs
firmware and that the purpose of this patch is to work around the core's
handling of the firmware.
>
> Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 67 ++++++++++++++++++++++------
> include/linux/remoteproc.h | 2 +
> 2 files changed, 55 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
[..]
> @@ -1758,11 +1779,20 @@ int rproc_boot(struct rproc *rproc)
>
> dev_info(dev, "powering up %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;
> + if (!rproc->skip_fw_load) {
> + /* 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;
> + }
> + } else {
> + /*
> + * Set firmware name pointer to null as remoteproc core is not
> + * in charge of firmware loading
> + */
> + kfree(rproc->firmware);
> + rproc->firmware = NULL;
As stated before, I think it would be more appropriate to allow a
remoteproc driver for hardware that shouldn't have firmware loaded to
never set rproc->firmware.
And I'm still curious how you're dealing with a crash or a restart on
this remoteproc. Don't you need to reload your firmware in these
circumstances? Do you perhaps have a remoteproc that's both
"already_booted" and "skip_fw_load"?
> }
>
> ret = rproc_fw_boot(rproc, firmware_p);
> @@ -1916,8 +1946,17 @@ int rproc_add(struct rproc *rproc)
> /* create debugfs entries */
> rproc_create_debug_dir(rproc);
>
> - /* if rproc is marked always-on, request it to boot */
> - if (rproc->auto_boot) {
> + if (rproc->skip_fw_load) {
> + /*
> + * If rproc is marked already booted, no need to wait
> + * for firmware.
> + * Just handle associated resources and start sub devices
> + */
Again, this describes a system where the remoteproc is already booted,
not a remoteproc that doesn't need firmware loading.
Regards,
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
Ohad Ben-Cohen <ohad@wizery.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Loic PALLARDY <loic.pallardy@st.com>, Suman Anna <s-anna@ti.com>,
Fabien DESSENNE <fabien.dessenne@st.com>,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v5 1/3] remoteproc: add support for co-processor loaded and booted before kernel
Date: Thu, 13 Feb 2020 18:55:12 -0800 [thread overview]
Message-ID: <20200214025512.GQ1443@yoga> (raw)
In-Reply-To: <20200211174205.22247-2-arnaud.pouliquen@st.com>
On Tue 11 Feb 09:42 PST 2020, Arnaud Pouliquen wrote:
> From: Loic Pallardy <loic.pallardy@st.com>
>
> Remote processor could boot independently or be loaded/started before
> Linux kernel by bootloader or any firmware.
> This patch introduces a new property in rproc core, named skip_fw_load,
> to be able to allocate resources and sub-devices like vdev and to
> synchronize with current state without loading firmware from file system.
This sentence describes the provided patch.
As I expressed in the earlier version, in order to support remoteprocs
that doesn't need firmware loading, e.g. running from some ROM or
dedicated flash storage etc, this patch looks really good.
> It is platform driver responsibility to implement the right firmware
> load ops according to HW specificities.
But this last sentence describes a remoteproc that indeed needs
firmware and that the purpose of this patch is to work around the core's
handling of the firmware.
>
> Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 67 ++++++++++++++++++++++------
> include/linux/remoteproc.h | 2 +
> 2 files changed, 55 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
[..]
> @@ -1758,11 +1779,20 @@ int rproc_boot(struct rproc *rproc)
>
> dev_info(dev, "powering up %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;
> + if (!rproc->skip_fw_load) {
> + /* 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;
> + }
> + } else {
> + /*
> + * Set firmware name pointer to null as remoteproc core is not
> + * in charge of firmware loading
> + */
> + kfree(rproc->firmware);
> + rproc->firmware = NULL;
As stated before, I think it would be more appropriate to allow a
remoteproc driver for hardware that shouldn't have firmware loaded to
never set rproc->firmware.
And I'm still curious how you're dealing with a crash or a restart on
this remoteproc. Don't you need to reload your firmware in these
circumstances? Do you perhaps have a remoteproc that's both
"already_booted" and "skip_fw_load"?
> }
>
> ret = rproc_fw_boot(rproc, firmware_p);
> @@ -1916,8 +1946,17 @@ int rproc_add(struct rproc *rproc)
> /* create debugfs entries */
> rproc_create_debug_dir(rproc);
>
> - /* if rproc is marked always-on, request it to boot */
> - if (rproc->auto_boot) {
> + if (rproc->skip_fw_load) {
> + /*
> + * If rproc is marked already booted, no need to wait
> + * for firmware.
> + * Just handle associated resources and start sub devices
> + */
Again, this describes a system where the remoteproc is already booted,
not a remoteproc that doesn't need firmware loading.
Regards,
Bjorn
next prev parent reply other threads:[~2020-02-14 2:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 17:42 [PATCH v5 0/3] add support for co-processor loaded and booted before kernel Arnaud Pouliquen
2020-02-11 17:42 ` Arnaud Pouliquen
2020-02-11 17:42 ` [PATCH v5 1/3] remoteproc: " Arnaud Pouliquen
2020-02-11 17:42 ` Arnaud Pouliquen
2020-02-13 20:08 ` Mathieu Poirier
2020-02-14 16:33 ` Arnaud POULIQUEN
2020-02-14 16:33 ` Arnaud POULIQUEN
2020-02-17 18:40 ` Mathieu Poirier
2020-02-18 17:31 ` Arnaud POULIQUEN
2020-02-18 17:31 ` Arnaud POULIQUEN
2020-02-19 20:56 ` Mathieu Poirier
2020-02-20 9:35 ` Arnaud POULIQUEN
2020-02-20 9:35 ` Arnaud POULIQUEN
2020-02-20 21:40 ` Mathieu Poirier
2020-02-27 0:56 ` Mathieu Poirier
2020-02-27 6:25 ` Peng Fan
2020-03-09 13:43 ` Arnaud POULIQUEN
2020-03-09 13:43 ` Arnaud POULIQUEN
2020-02-28 3:40 ` Suman Anna
2020-02-28 3:40 ` Suman Anna
2020-02-14 2:55 ` Bjorn Andersson [this message]
2020-02-14 2:55 ` Bjorn Andersson
2020-02-14 16:34 ` Arnaud POULIQUEN
2020-02-14 16:34 ` Arnaud POULIQUEN
2020-02-11 17:42 ` [PATCH v5 2/3] remoteproc: stm32: add support for co-processor " Arnaud Pouliquen
2020-02-11 17:42 ` Arnaud Pouliquen
2020-02-13 20:34 ` Mathieu Poirier
2020-02-14 16:39 ` Arnaud POULIQUEN
2020-02-14 16:39 ` Arnaud POULIQUEN
2020-02-14 3:38 ` Bjorn Andersson
2020-02-14 3:38 ` Bjorn Andersson
2020-02-14 16:49 ` Arnaud POULIQUEN
2020-02-14 16:49 ` Arnaud POULIQUEN
2020-02-11 17:42 ` [PATCH v5 3/3] dt-bindings: remoteproc: stm32: add syscon bindings preloaded fw support Arnaud Pouliquen
2020-02-11 17:42 ` Arnaud Pouliquen
2020-02-18 21:00 ` Rob Herring
2020-02-18 21:00 ` Rob Herring
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=20200214025512.GQ1443@yoga \
--to=bjorn.andersson@linaro.org \
--cc=arnaud.pouliquen@st.com \
--cc=devicetree@vger.kernel.org \
--cc=fabien.dessenne@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=loic.pallardy@st.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=ohad@wizery.com \
--cc=robh+dt@kernel.org \
--cc=s-anna@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.