Hi Suman, On Tue, Sep 16, 2014 at 7:14 PM, Suman Anna <s-anna@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
