All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: loic pallardy <loic.pallardy@st.com>
Cc: linux-remoteproc@vger.kernel.org,
	Ohad Ben-Cohen <ohad@wizery.com>,
	linux-kernel@vger.kernel.org, Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 1/4] remoteproc: Introduce always-on flag
Date: Wed, 3 Aug 2016 15:02:31 -0700	[thread overview]
Message-ID: <20160803220231.GF13516@tuxbot> (raw)
In-Reply-To: <57A0B99F.6040206@st.com>

On Tue 02 Aug 08:17 PDT 2016, loic pallardy wrote:

> Hi Bjorn,
> 
> On 08/01/2016 08:58 PM, Bjorn Andersson wrote:
> >Introduce an "always-on" flag on rprocs to make it possible to flag
> >remote processors without vdevs to automatically boot once the firmware
> >is found.
> >
> Should this flag rather be named "auto-boot"? From my pov, "always-on" means
> coprocessor can't be shutdown.
> 

I saw it from the view of the remoteproc driver, in which case it's
always-on. But I'm fine with naming it "auto-boot" instead.

[..]
> >diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
[..]
> >@@ -978,11 +982,16 @@ static int rproc_add_virtio_devices(struct rproc *rproc)
> >  int rproc_trigger_recovery(struct rproc *rproc)
> >  {
> >  	struct rproc_vdev *rvdev, *rvtmp;
> >+	int ret;
> >
> >  	dev_err(&rproc->dev, "recovering %s\n", rproc->name);
> >
> >  	init_completion(&rproc->crash_comp);
> >
> >+	/* shut down the remote */
> >+	/* TODO: make sure this works with rproc->power > 1 */
> >+	rproc_shutdown(rproc);
> >+
> >  	/* clean up remote vdev entries */
> >  	list_for_each_entry_safe(rvdev, rvtmp, &rproc->rvdevs, node)
> >  		rproc_remove_virtio_dev(rvdev);
> >@@ -993,7 +1002,17 @@ int rproc_trigger_recovery(struct rproc *rproc)
> >  	/* Free the copy of the resource table */
> >  	kfree(rproc->cached_table);
> >
> >-	return rproc_add_virtio_devices(rproc);
> >+	ret = rproc_add_virtio_devices(rproc);
> >+	if (ret)
> >+		return ret;
> >+
> >+	/*
> >+	 * boot the remote processor up again, waiting for the async fw load to
> >+	 * finish
> >+	 */
> >+	rproc_boot(rproc);
> You are changing current behavior by forcing rproc boot whatever
> "always-on". Moreover coprocessor already rebooted by
> rproc_add_virtio_device if "always-on" flag is set, doesn't it?
> If yes, rproc->power will be equal to 2 and rproc_shutdown call will failed
> as this second rproc_boot call is unknown from customer pov.
> 

rproc_add_virtio_devices() does no longer call rproc_boot(), this patch
moves that call. So for always-on rprocs "power" will go 1 -> 0 -> 1 in
this function.

What does change is that for a non-always-on case.

If we have 1 client that has requested rproc_boot() then the current
implementation will bring "power" down to 1 and we will wait until the
client for some reason calls rproc_shutdown(). After that we might boot
the system again, if there are any vdevs in the resource table.

Here we will bring "power" from 1 -> 0 -> 1, without regarding who's
holding references.

> >+
> >+	return 0;
> >  }

Regards,
Bjorn

  reply	other threads:[~2016-08-03 22:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-01 18:58 [PATCH 1/4] remoteproc: Introduce always-on flag Bjorn Andersson
2016-08-01 18:58 ` [PATCH 2/4] remoteproc: Calculate max_notifyid during load Bjorn Andersson
2016-08-01 18:58 ` [PATCH 3/4] remoteproc: Move vdev handling to boot/shutdown Bjorn Andersson
2016-08-02 15:17   ` loic pallardy
2016-08-02 15:17     ` loic pallardy
2016-08-03 18:17     ` Bjorn Andersson
2016-08-01 18:58 ` [PATCH 4/4] remoteproc: Move handling of cached table " Bjorn Andersson
2016-08-02 15:17 ` [PATCH 1/4] remoteproc: Introduce always-on flag loic pallardy
2016-08-02 15:17   ` loic pallardy
2016-08-03 22:02   ` Bjorn Andersson [this message]
2016-08-04  9:44     ` loic pallardy
2016-08-04  9:44       ` loic pallardy
2016-08-04 17:23       ` Bjorn Andersson

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=20160803220231.GF13516@tuxbot \
    --to=bjorn.andersson@linaro.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=ohad@wizery.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.