public inbox for linux-remoteproc@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: linux-remoteproc@vger.kernel.org,
	Loic PALLARDY <loic.pallardy@st.com>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	Suman Anna <s-anna@ti.com>
Subject: Re: [RFC 1/6] remoteproc: add early probed subdevices
Date: Wed, 13 Dec 2017 22:11:02 -0800	[thread overview]
Message-ID: <20171214061102.GR17344@builder> (raw)
In-Reply-To: <1511534202-12995-2-git-send-email-arnaud.pouliquen@st.com>

On Fri 24 Nov 06:36 PST 2017, Arnaud Pouliquen wrote:

> From: Fabien Dessenne <fabien.dessenne@st.com>
> 
> Add the option to use rproc subdevices that are probed *before* the
> remote processor firmware boot.
> 

Rather than adding a somewhat obscure variant of subdevices I think you
should take Loic's addition of a "release" callback on the memory node
and turn this into a struct rproc_resource that can be embedded in
various resource-types (using container_of to grab the specific struct).

Transitioning carveouts, mappings, vrings etc to using this should allow
us to turn all the different lists of resources that should be
acquired before boot and released after shutdown.


And rather than starting by introducing the SRM I would like to see an
example that hands over the control of "clk" in imx_rproc.c to the
remoteproc core (this is the simplest example I could find).

This can then be built upon to allow referencing additional clocks to
enable statically, by name, from the resource table.

> @@ -881,20 +881,27 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
>  		rproc->table_ptr = loaded_table;
>  	}
>  
> +	/* early probe any subdevices for the remote processor */
> +	ret = rproc_probe_subdevices(&rproc->early_subdevs);
> +	if (ret) {
> +		dev_err(dev, "failed to early probe subdevices for %s: %d\n",
> +			rproc->name, ret);
> +		return ret;

Enabling the "early" resources this late will make it infeasible to use
for things like clocking memories of the remoteproc.

> @@ -1028,6 +1041,9 @@ static int rproc_stop(struct rproc *rproc)
>  		return ret;
>  	}
>  
> +	/* remove any early-probed subdevices for the remote processor */
> +	rproc_remove_subdevices(&rproc->early_subdevs);
> +

This will cause "early subdevs" to be disabled during recovery, just to
be enabled immediately again.

So I think that like the memory resources we want to hold on to them
from boot to shutdown. Preferably in a way that allows us to provide the
ordering that allow us to use this mechanism to describe clocks for
memories in the remoteproc.

Regards,
Bjorn

  reply	other threads:[~2017-12-14  6:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 14:36 [RFC 0/6] System resource management Arnaud Pouliquen
2017-11-24 14:36 ` [RFC 1/6] remoteproc: add early probed subdevices Arnaud Pouliquen
2017-12-14  6:11   ` Bjorn Andersson [this message]
2017-11-24 14:36 ` [RFC 2/6] dt-bindings: remoteproc: add system resource manager (SRM) Arnaud Pouliquen
2017-12-14  5:59   ` Bjorn Andersson
2017-12-21 17:46     ` Arnaud Pouliquen
2017-11-24 14:36 ` [RFC 3/6] remoteproc: add system resource manager core Arnaud Pouliquen
2017-12-14  6:15   ` Bjorn Andersson
2017-11-24 14:36 ` [RFC 4/6] remoteproc: add system resource manager device Arnaud Pouliquen
2017-11-24 14:36 ` [RFC 5/6] remoteproc: Add posibility to probe a sub device Arnaud Pouliquen
2017-12-14  6:24   ` Bjorn Andersson
2017-11-24 14:36 ` [RFC 6/6] remoteproc: sti: select srm Arnaud Pouliquen

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=20171214061102.GR17344@builder \
    --to=bjorn.andersson@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=fabien.dessenne@st.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox