On Fri, 06 May 2016, Bjorn Andersson wrote: > On Thu 05 May 06:29 PDT 2016, Lee Jones wrote: > > > ST Co-Processors can be loaded with different firmwares to execute > > specific tasks without the need for unloading the rproc module. > > > > I'm very much interested in ideas related to this and who "owns" the > life cycle of remoteprocs, do you have any code I can take a look at > that's using this interface? I was part of a conversation on the list which should explain some of your queries [0]. The conclusion was, that only the client can know what which firmware it is compatible with. This information can not realistically either live in DT (or any other platform data) or within RemoteProc. I hope that link answers your questions. [0] http://www.spinics.net/lists/devicetree-spec/msg00144.html > > This patch provides a function which can update the firmware name. > > > > NB: This can only happen if the rproc is offline. > > How is this working in the case when the remoteproc provides vdevs that > is holding references towards the rproc? > > Do you unload rpmsg et al before doing this? RemoteProc needs to be offline for the firmware name to be set, this includes links to RPMsg, so yes, they would have to be unloaded. > > Signed-off-by: Ludovic Barre <ludovic.barre@xxxxxx> > > Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> > > --- > > drivers/remoteproc/remoteproc_core.c | 63 ++++++++++++++++++++++++++++++++++++ > > include/linux/remoteproc.h | 13 ++++++++ > > 2 files changed, 76 insertions(+) Happy with the remainder of your comments -- will fix. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html