Re: [PATCH 05/13] remoteproc: Add new detach() remoteproc operation

[Mathieu Poirier]

Hi Peng - I restarting work on this topic.

On Thu, Oct 15, 2020 at 01:37:42AM +0000, Peng Fan wrote:
> > Subject: [PATCH 05/13] remoteproc: Add new detach() remoteproc operation
> > 
> > Add an new detach() operation in order to support scenarios where the
> > remoteproc core is going away but the remote processor is kept operating.
> > This could be the case when the system is rebooted or when the platform
> > driver is removed.
> > 
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>
> > ---
> >  include/linux/remoteproc.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h index
> > fe383392a821..1a57e165da2c 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -361,6 +361,7 @@ enum rsc_handling_status {
> >   * @start:	power on the device and boot it
> >   * @stop:	power off the device
> >   * @attach:	attach to a device that his already powered up
> > + * @detach:	tell the remote processor that the core is going away
> >   * @kick:	kick a virtqueue (virtqueue id given as a parameter)
> >   * @da_to_va:	optional platform hook to perform address translations
> >   * @parse_fw:	parse firmware to extract information (e.g. resource table)
> > @@ -382,6 +383,7 @@ struct rproc_ops {
> >  	int (*start)(struct rproc *rproc);
> >  	int (*stop)(struct rproc *rproc);
> >  	int (*attach)(struct rproc *rproc);
> > +	int (*detach)(struct rproc *rproc);
> >  	void (*kick)(struct rproc *rproc, int vqid);
> >  	void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len);
> >  	int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
> > --
> 
> This look useful for i.MX8 partitioned case, M4 and A53 could reboot without
> impacting the other. When A53 reboot, detach is invoked if I understand correct.

You are correct (for this patchset).  Since this heuristic is quite stringent we are
contemplating different solutions that would allow platforms to decide what they
want to do based on the usecase they care about.

Thanks,
Mathieu

> 
> Reviewed-by: Peng Fan <peng.fan@xxxxxxx>