devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julien Massot <julien.massot@iot.bzh>
To: Biju Das <biju.das.jz@bp.renesas.com>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"mathieu.poirier@linaro.org" <mathieu.poirier@linaro.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>
Cc: "linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v1 3/3] remoteproc: Add Renesas rcar driver
Date: Mon, 15 Nov 2021 15:41:19 +0100	[thread overview]
Message-ID: <ebca7899-1b7e-66d4-f022-576b18b9bc95@iot.bzh> (raw)
In-Reply-To: <OS0PR01MB5922D67AEFD75847CE5B0DD586989@OS0PR01MB5922.jpnprd01.prod.outlook.com>

Hi Biju,

> 
> One question CR7 Can be master boot processor. In that case
> How to avoid loading and booting  CR7 processor from Linux?
> Reading boot modes??
> 
Thanks for the question.

I did not test this case. There is also other scenarios where the
Cortex-R7 is started by an earlier component such as BL2, u-boot or
OP-Tee.
In these cases Linux should not try to start / stop this remote processor.
One idea could be to read the power status CR7PSTR / PWRSR7, or use
one of the MFIS register as a communication register. STM32 processor
use this last solution to indicate that the remote processor is
already started, in that scenario remoteproc driver starts in 'detached' state
instead of 'offline' state.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/remoteproc.h#n418

In that state, remoteproc driver can initiate communication with
this remote processor but will not try to start or to stop it.

That's something I have in mind, with an existing implementation there
https://github.com/iotbzh/linux/blob/iot/julien/rproc/drivers/remoteproc/rcar_rproc.c#L524
(that is not ready for upstream yet :)).

I guess this issue also exists when one device is dedicated to the secure world, so
the device exists, but not available for Linux. The most obvious (and dirty ?) solution is to keep
the device disabled in dts.

Regards,
Julien


  reply	other threads:[~2021-11-15 14:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 13:50 [PATCH v1 0/3] Initial Renesas R-Car remoteproc support Julien Massot
2021-11-15 13:50 ` [PATCH v1 1/3] dt-bindings: remoteproc: Add Renesas R-Car Julien Massot
2021-11-29 22:01   ` Rob Herring
2021-11-30  8:51     ` Julien Massot
2021-11-15 13:50 ` [PATCH v1 2/3] arm64: dts: renesas: r8a77951: Add CR7 realtime processor Julien Massot
2022-01-10 13:00   ` Geert Uytterhoeven
2021-11-15 13:50 ` [PATCH v1 3/3] remoteproc: Add Renesas rcar driver Julien Massot
2021-11-15 14:12   ` Biju Das
2021-11-15 14:41     ` Julien Massot [this message]
2021-11-15 15:17       ` Biju Das
2021-11-22 18:37   ` Mathieu Poirier
2021-11-24 11:07     ` Julien Massot
2021-11-24 17:35       ` Mathieu Poirier
2021-11-15 18:10 ` [PATCH v1 0/3] Initial Renesas R-Car remoteproc support Mathieu Poirier

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=ebca7899-1b7e-66d4-f022-576b18b9bc95@iot.bzh \
    --to=julien.massot@iot.bzh \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).