| Message ID | 20200424200135.28825-1-mathieu.poirier@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | remoteproc: Add support for synchronisaton with rproc | expand |
> 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
On Mon, 18 May 2020 at 07:28, Peng Fan <peng.fan@nxp.com> wrote: > > > 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? It will not be applied as more work needs to be done. As one of the people this feature will benefit, it would be really nice if you could take the time to comment on the solution that is brought forward. > > 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 >