All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Clément Leger" <cleger@kalray.eu>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Fabien DESSENNE <fabien.dessenne@st.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	od@zcrc.me, linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/5] remoteproc: Add prepare/unprepare callbacks
Date: Mon, 16 Dec 2019 09:42:51 +0100 (CET)	[thread overview]
Message-ID: <1428337657.96784882.1576485771590.JavaMail.zimbra@kalray.eu> (raw)
In-Reply-To: <1576362603.3.5@crapouillou.net>

Hi Paul

----- On 14 Dec, 2019, at 23:30, Paul Cercueil paul@crapouillou.net wrote:

> Hi Fabien,
> 
> 
> Le jeu., déc. 12, 2019 at 10:03, Fabien DESSENNE
> <fabien.dessenne@st.com> a écrit :
>> Hi Paul
>> 
>> 
>> On 10/12/2019 5:40 PM, Paul Cercueil wrote:
>>>  The .prepare() callback is called before the firmware is loaded to
>>>  memory. This is useful for instance in the case where some setup is
>>>  required for the memory to be accessible.
>> 
>> 
>> I am trying to figure out what king of 'setup' may be required. From
>> the
>> ingenic driver I understand that you need to enable clocks to allow
>> some
>> memory access.
>> 
>> Instead of adding this new ops, why not enabling clocks in probe()?
> 
> Enabling the clocks in the probe means that the clocks will be
> unconditionally enabled until the driver is removed, even if the remote
> processor end up being unused. That would be a waste of power.

We have the same kind of "problem" for k1c remoteproc driver (not yet
upstream, depends on new arch). We need to enable clocks to load code
into remote processor memory and currently we do that in probe.
However, as you stated, we would like to enable them as late as possible
(just before loading code) to avoid wasting power unnecessarily. So the
"prepare" callback totally makes sense.

Regards,

Clément

> 
> Cheers,
> -Paul
> 
> 
>> 
>> BR
>> 
>> Fabien
>> 
>> 
>>> 
>>>  Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>>  ---
>>> 
>>>  Notes:
>>>       v2-v4: No change
>>> 
>>>    drivers/remoteproc/remoteproc_core.c | 16 +++++++++++++++-
>>>    include/linux/remoteproc.h           |  4 ++++
>>>    2 files changed, 19 insertions(+), 1 deletion(-)
>>> 
>>>  diff --git a/drivers/remoteproc/remoteproc_core.c
>>> b/drivers/remoteproc/remoteproc_core.c
>>>  index 0a9fc7fdd1c3..3ea5f675a148 100644
>>>  --- a/drivers/remoteproc/remoteproc_core.c
>>>  +++ b/drivers/remoteproc/remoteproc_core.c
>>>  @@ -1299,11 +1299,19 @@ static int rproc_start(struct rproc *rproc,
>>> const struct firmware *fw)
>>>    	struct device *dev = &rproc->dev;
>>>    	int ret;
>>> 
>>>  +	if (rproc->ops->prepare) {
>>>  +		ret = rproc->ops->prepare(rproc);
>>>  +		if (ret) {
>>>  +			dev_err(dev, "Failed to prepare rproc: %d\n", ret);
>>>  +			return ret;
>>>  +		}
>>>  +	}
>>>  +
>>>    	/* load the ELF segments to memory */
>>>    	ret = rproc_load_segments(rproc, fw);
>>>    	if (ret) {
>>>    		dev_err(dev, "Failed to load program segments: %d\n", ret);
>>>  -		return ret;
>>>  +		goto unprepare_rproc;
>>>    	}
>>> 
>>>    	/*
>>>  @@ -1354,6 +1362,9 @@ static int rproc_start(struct rproc *rproc,
>>> const struct firmware *fw)
>>>    	rproc_unprepare_subdevices(rproc);
>>>    reset_table_ptr:
>>>    	rproc->table_ptr = rproc->cached_table;
>>>  +unprepare_rproc:
>>>  +	if (rproc->ops->unprepare)
>>>  +		rproc->ops->unprepare(rproc);
>>> 
>>>    	return ret;
>>>    }
>>>  @@ -1483,6 +1494,9 @@ static int rproc_stop(struct rproc *rproc,
>>> bool crashed)
>>> 
>>>    	rproc->state = RPROC_OFFLINE;
>>> 
>>>  +	if (rproc->ops->unprepare)
>>>  +		rproc->ops->unprepare(rproc);
>>>  +
>>>    	dev_info(dev, "stopped remote processor %s\n", rproc->name);
>>> 
>>>    	return 0;
>>>  diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>>  index 5f201f0c86c3..a6272d1ba384 100644
>>>  --- a/include/linux/remoteproc.h
>>>  +++ b/include/linux/remoteproc.h
>>>  @@ -355,6 +355,8 @@ enum rsc_handling_status {
>>> 
>>>    /**
>>>     * struct rproc_ops - platform-specific device handlers
>>>  + * @prepare:	prepare the device for power up (before the firmware
>>> is loaded)
>>>  + * @unprepare:	unprepare the device after it is stopped
>>>     * @start:	power on the device and boot it
>>>     * @stop:	power off the device
>>>     * @kick:	kick a virtqueue (virtqueue id given as a parameter)
>>>  @@ -371,6 +373,8 @@ enum rsc_handling_status {
>>>     * @get_boot_addr:	get boot address to entry point specified in
>>> firmware
>>>     */
>>>    struct rproc_ops {
>>>  +	int (*prepare)(struct rproc *rproc);
>>>  +	void (*unprepare)(struct rproc *rproc);
>>>    	int (*start)(struct rproc *rproc);
>>>    	int (*stop)(struct rproc *rproc);
> >>    	void (*kick)(struct rproc *rproc, int vqid);

  reply	other threads:[~2019-12-16  8:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 16:40 [PATCH v4 1/5] dt-bindings: Document JZ47xx VPU auxiliary processor Paul Cercueil
2019-12-10 16:40 ` [PATCH v4 2/5] remoteproc: Add device-managed variants of rproc_alloc/rproc_add Paul Cercueil
2019-12-12  9:43   ` Fabien DESSENNE
2019-12-14 22:27     ` Paul Cercueil
2020-01-20 19:45     ` Bjorn Andersson
2020-01-20 19:45       ` Bjorn Andersson
2019-12-16 10:46   ` Clément Leger
2019-12-16 13:41     ` Paul Cercueil
2020-01-20 20:07   ` Bjorn Andersson
2020-01-20 20:07     ` Bjorn Andersson
2019-12-10 16:40 ` [PATCH v4 3/5] remoteproc: Add prepare/unprepare callbacks Paul Cercueil
2019-12-12 10:03   ` Fabien DESSENNE
2019-12-14 22:30     ` Paul Cercueil
2019-12-16  8:42       ` Clément Leger [this message]
2019-12-16 16:16         ` Clément Leger
2019-12-17 10:21       ` Fabien DESSENNE
2019-12-21 20:20   ` Bjorn Andersson
2019-12-21 20:20     ` Bjorn Andersson
2020-01-15 21:15     ` Paul Cercueil
2020-01-20 20:19       ` Bjorn Andersson
2020-01-20 20:19         ` Bjorn Andersson
2020-01-21 10:24         ` Arnaud POULIQUEN
2020-01-21 10:24           ` Arnaud POULIQUEN
2019-12-10 16:40 ` [PATCH v4 4/5] remoteproc: ingenic: Added remoteproc driver Paul Cercueil
2019-12-10 16:40 ` [PATCH v4 5/5] MAINTAINERS: Add myself as reviewer for Ingenic rproc driver Paul Cercueil
2019-12-13 19:02 ` [PATCH v4 1/5] dt-bindings: Document JZ47xx VPU auxiliary processor Rob Herring
2019-12-13 21:27   ` Paul Cercueil

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=1428337657.96784882.1576485771590.JavaMail.zimbra@kalray.eu \
    --to=cleger@kalray.eu \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabien.dessenne@st.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=od@zcrc.me \
    --cc=ohad@wizery.com \
    --cc=paul@crapouillou.net \
    --cc=robh+dt@kernel.org \
    /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.