| Message ID | 20201030195713.1366341-8-mathieu.poirier@linaro.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | remoteproc: Add support for detaching from rproc | expand |
On 10/30/20 8:57 PM, Mathieu Poirier wrote: > Introduce function __rproc_detach() to perform the same kind of > operation as rproc_stop(), but instead of switching off the > remote processor using rproc->ops->stop(), it uses > rproc->ops->detach(). That way it is possible for the core > to release the resources associated with a remote processor while > the latter is kept operating. > > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> > Reviewed-by: Peng Fan <peng.fan@nxp.com> > --- > drivers/remoteproc/remoteproc_core.c | 31 ++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index ed1f9ca4248b..62e88ff65009 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1664,6 +1664,37 @@ static int rproc_stop(struct rproc *rproc, bool crashed) > return 0; > } > > +/* > + * __rproc_detach(): Does the opposite of rproc_attach() > + */ > +static int __maybe_unused __rproc_detach(struct rproc *rproc) > +{ > + struct device *dev = &rproc->dev; > + int ret; > + > + /* No need to continue if a detach() operation has not been provided */ > + if (!rproc->ops->detach) > + return -EINVAL; > + > + /* Stop any subdevices for the remote processor */ > + rproc_stop_subdevices(rproc, false); How to determine whether a subdevice should be stopped or detached? For instance, in ST, we have a resource manager subdev which maintains clocks and regulators for peripherals used by the remote processor. In case of detachment we would need to maintain clock and regulators. > + > + /* Tell the remote processor the core isn't available anymore */ > + ret = rproc->ops->detach(rproc); > + if (ret) { > + dev_err(dev, "can't detach from rproc: %d\n", ret); > + rproc_start_subdevices(rproc); > + return ret; > + } > + > + rproc_unprepare_subdevices(rproc); Same here, is prepare/unprepare can depend on the operation? Seems that adding rproc_attach_subdevices/rproc_detach_subdevices could be not sufficient to address prepare/unprepare. Alternative could be: - extra parameter for the subdev ops to indicate attach/detach action...? - intermediate rproc state : ATTACHING, DETACHING - other? That's said, I don't think that it is blocking for the ST resource manager. In this particular case, regulators and clocks can be permanently activated as a back-up solution (always-on). So, if no other company has a problem with that, we can keep this implementation for now. Regards, Arnaud > + > + rproc->state = RPROC_DETACHED; > + > + dev_info(dev, "detached remote processor %s\n", rproc->name); > + > + return 0; > +} > > /** > * rproc_trigger_recovery() - recover a remoteproc >
On Fri, Nov 06, 2020 at 06:43:05PM +0100, Arnaud POULIQUEN wrote: > > > On 10/30/20 8:57 PM, Mathieu Poirier wrote: > > Introduce function __rproc_detach() to perform the same kind of > > operation as rproc_stop(), but instead of switching off the > > remote processor using rproc->ops->stop(), it uses > > rproc->ops->detach(). That way it is possible for the core > > to release the resources associated with a remote processor while > > the latter is kept operating. > > > > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> > > Reviewed-by: Peng Fan <peng.fan@nxp.com> > > --- > > drivers/remoteproc/remoteproc_core.c | 31 ++++++++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > > index ed1f9ca4248b..62e88ff65009 100644 > > --- a/drivers/remoteproc/remoteproc_core.c > > +++ b/drivers/remoteproc/remoteproc_core.c > > @@ -1664,6 +1664,37 @@ static int rproc_stop(struct rproc *rproc, bool crashed) > > return 0; > > } > > > > +/* > > + * __rproc_detach(): Does the opposite of rproc_attach() > > + */ > > +static int __maybe_unused __rproc_detach(struct rproc *rproc) > > +{ > > + struct device *dev = &rproc->dev; > > + int ret; > > + > > + /* No need to continue if a detach() operation has not been provided */ > > + if (!rproc->ops->detach) > > + return -EINVAL; > > + > > + /* Stop any subdevices for the remote processor */ > > + rproc_stop_subdevices(rproc, false); > > How to determine whether a subdevice should be stopped or detached? > For instance, in ST, we have a resource manager subdev which maintains clocks and regulators > for peripherals used by the remote processor. > In case of detachment we would need to maintain clock and regulators. > > > + > > + /* Tell the remote processor the core isn't available anymore */ > > + ret = rproc->ops->detach(rproc); > > + if (ret) { > > + dev_err(dev, "can't detach from rproc: %d\n", ret); > > + rproc_start_subdevices(rproc); > > + return ret; > > + } > > + > > + rproc_unprepare_subdevices(rproc); > > Same here, is prepare/unprepare can depend on the operation? > > Seems that adding rproc_attach_subdevices/rproc_detach_subdevices could be not sufficient > to address prepare/unprepare. > Alternative could be: > - extra parameter for the subdev ops to indicate attach/detach action...? > - intermediate rproc state : ATTACHING, DETACHING > - other? These are really good points. I did not think about that kind of scenario and the best solution isn't obvious to me either. > > That's said, I don't think that it is blocking for the ST resource manager. > In this particular case, regulators and clocks can be permanently activated > as a back-up solution (always-on). > > So, if no other company has a problem with that, we can keep this implementation for now. As I wrote above the path forward isn't clear to me and as such will opt to address this in another patchset... But it has to be fixed. > > Regards, > Arnaud > > > + > > + rproc->state = RPROC_DETACHED; > > + > > + dev_info(dev, "detached remote processor %s\n", rproc->name); > > + > > + return 0; > > +} > > > > /** > > * rproc_trigger_recovery() - recover a remoteproc > >
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index ed1f9ca4248b..62e88ff65009 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1664,6 +1664,37 @@ static int rproc_stop(struct rproc *rproc, bool crashed) return 0; } +/* + * __rproc_detach(): Does the opposite of rproc_attach() + */ +static int __maybe_unused __rproc_detach(struct rproc *rproc) +{ + struct device *dev = &rproc->dev; + int ret; + + /* No need to continue if a detach() operation has not been provided */ + if (!rproc->ops->detach) + return -EINVAL; + + /* Stop any subdevices for the remote processor */ + rproc_stop_subdevices(rproc, false); + + /* Tell the remote processor the core isn't available anymore */ + ret = rproc->ops->detach(rproc); + if (ret) { + dev_err(dev, "can't detach from rproc: %d\n", ret); + rproc_start_subdevices(rproc); + return ret; + } + + rproc_unprepare_subdevices(rproc); + + rproc->state = RPROC_DETACHED; + + dev_info(dev, "detached remote processor %s\n", rproc->name); + + return 0; +} /** * rproc_trigger_recovery() - recover a remoteproc