[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB6PR0402MB2760B52EDFD1DB20AE0BDE3588B80@DB6PR0402MB2760.eurprd04.prod.outlook.com>
Date: Mon, 18 May 2020 13:28:11 +0000
From: Peng Fan <peng.fan@....com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>,
"bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
"ohad@...ery.com" <ohad@...ery.com>
CC: "loic.pallardy@...com" <loic.pallardy@...com>,
"arnaud.pouliquen@...com" <arnaud.pouliquen@...com>,
"s-anna@...com" <s-anna@...com>,
"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
"corbet@....net" <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 00/14] remoteproc: Add support for synchronisaton with
rproc
> Subject: [PATCH v3 00/14] remoteproc: Add support for synchronisaton with
> rproc
What's the status of this thread? Will this be applied or requires a new v4?
Thanks,
Peng.
>
> This is the third revision of this series that tries to address the problem of
> synchronising with a remote processor with as much flexibility as possible.
>
> Two things to pay attention to:
>
> 1) Function rproc_actuate() has been abandoned to avoid creating another
> way to start a remote processor from a kernel driver. Arnaud expressed
> the opinion that it is semantically questionnable to synchronise with a
> remote processor when calling rproc_boot(). We could rename
> rproc_boot() to rproc_actuate() but I'll wait to see what other people
> think before doing so.
>
> 2) The allocation of the synchronisation states has been split from the
> remote processor allocation. A new function rproc_set_state_machine()
> does all the work now. Proceeding this way has made the patchset a
> lot more simple.
>
> Other than the above I have tried to address all the comments made on the
> second revision. If a comment was not addressed it simply fell through the
> cracks rather than ignored. In such a case please reiterate your point
> of view and I'll be sure to address it.
>
> Applies cleanly on rproc-next (305ac5a766b1).
>
> Best regards,
> Mathieu
>
> Mathieu Poirier (14):
> remoteproc: Make core operations optional
> remoteproc: Introduce function rproc_alloc_internals()
> remoteproc: Add new operation and flags for synchronistation
> remoteproc: Refactor function rproc_boot()
> remoteproc: Refactor function rproc_fw_boot()
> remoteproc: Refactor function rproc_trigger_auto_boot()
> remoteproc: Introducting new start and stop functions
> remoteproc: Call core functions based on synchronisation flag
> remoteproc: Deal with synchronisation when crashing
> remoteproc: Deal with synchronisation when shutting down
> remoteproc: Deal with synchronisation when changing FW image
> remoteproc: Introducing function rproc_set_state_machine()
> remoteproc: Document function rproc_set_state_machine()
> remoteproc: Expose synchronisation flags via debugfs
>
> Documentation/remoteproc.txt | 17 ++
> drivers/remoteproc/remoteproc_core.c | 197
> +++++++++++++++++++----
> drivers/remoteproc/remoteproc_debugfs.c | 21 +++
> drivers/remoteproc/remoteproc_internal.h | 123 +++++++++++++-
> drivers/remoteproc/remoteproc_sysfs.c | 24 ++-
> include/linux/remoteproc.h | 27 ++++
> 6 files changed, 372 insertions(+), 37 deletions(-)
>
> --
> 2.20.1
Powered by blists - more mailing lists