[PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Ohad Ben-Cohen]

Hi Suman,

On Tue, Sep 16, 2014 at 7:14 PM, Suman Anna <s-anna at ti.com> wrote:
> The current remoteproc infrastructure automatically calls rproc_boot
> only as part of the rpmsg/virtio stack (in remoteproc_virtio.c), but
> since the WkupM3 does not use rpmsg, there is no automatic booting of
> the WkupM3 processor.  This is the reason why rproc_boot is called as
> part of the WkupM3 driver probe sequence. What are your concerns here,
> and if you think this is not the right place do invoke rproc_boot, where
> do you expect it to be called?

The remoteproc layer is meant to hide hardware-specific details, and
allow high-level hardware-agnostic code to boot a remote processor, in
order to achieve some task, without even caring what kind of hardware
it is booting.

So generally we have some consumer driver asking remoteproc to boot a
remote processor, and in turn, remoteproc asking a hardware-specific
vendor driver to take care of the hardware details like actually
taking the remote processor out of reset.

The consumer driver is some code that deals with some hardware
agnostic task. Today the only consumer we have is rpmsg, so it's
perfectly reasonable if remoteproc needs to be adapted a bit to
accommodate other consumers as they show up.

Can you think of any component in your code that is not necessarily
hardware specific, and that one day might be useful for other vendors?
Can you describe the task you're trying to achieve, the entities
involved and the flow between them?

> Also do note that, there is no way
> at present to retrieve the struct rproc for a given remote processor, to
> be able to invoke the rproc_boot from a different layer.

It's perfectly ok to make struct rproc public if we have a consumer
that requires it.

> Splitting this would still require some kind of notifier from remoteproc
> for the other layers for them to know that the WkupM3 remote processor
> has been loaded and booted successfully. This is also done as part of
> the WkupM3 driver at the moment.

Are there entities, other than the one that calls rproc_boot, that
needs to know that the WkupM3 is up? if so, let's discuss who should
notify them - remoteproc or the actual invoker of rproc_boot. It
probably depends on who those entities are and what's their relation,
if any, to the WkupM3 driver.

Thanks,
Ohad.