linux-imx
Public
Source
committed 620b470bb41x
handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler==========================Remote Processor Framework==========================Introduction============Modern SoCs typically have heterogeneous remote processor devices in asymmetricmultiprocessing (AMP) configurations, which may be running different instancesof operating system, whether it's Linux or any other flavor of real-time OS.OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP.In a typical configuration, the dual cortex-A9 is running Linux in a SMPconfiguration, and each of the other three cores (two M3 cores and a DSP)is running its own instance of RTOS in an AMP configuration.The remoteproc framework allows different platforms/architectures tocontrol (power on, load firmware, power off) those remote processors whileabstracting the hardware differences, so the entire driver doesn't need to beduplicated. In addition, this framework also adds rpmsg virtio devicesfor remote processors that supports this kind of communication. This way,platform-specific remoteproc drivers only need to provide a few low-levelhandlers, and then all rpmsg drivers will then just work(for more information about the virtio-based rpmsg bus and its drivers,please read Documentation/rpmsg.txt).Registration of other types of virtio devices is now also possible. Firmwaresjust need to publish what kind of virtio devices do they support, and thenremoteproc will add those devices. This makes it possible to reuse theexisting virtio drivers with remote processor backends at a minimal developmentcost.User API========:: int rproc_boot(struct rproc *rproc)Boot a remote processor (i.e. load its firmware, power it on, ...).If the remote processor is already powered on, this function immediatelyreturns (successfully).Returns 0 on success, and an appropriate error value otherwise.Note: to use this function you should already have a valid rprochandle. There are several ways to achieve that cleanly (devres, pdata,the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, wemight also consider using dev_archdata for this).:: void rproc_shutdown(struct rproc *rproc)Power off a remote processor (previously booted with rproc_boot()).In case @rproc is still being used by an additional user(s), thenthis function will just decrement the power refcount and exit,without really powering off the device.Every call to rproc_boot() must (eventually) be accompanied by a callto rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug... note:: we're not decrementing the rproc's refcount, only the power refcount. which means that the @rproc handle stays valid even after rproc_shutdown() returns, and users can still use it with a subsequent rproc_boot(), if needed.:: struct rproc *rproc_get_by_phandle(phandle phandle)Find an rproc handle using a device tree phandle. Returns the rprochandle on success, and NULL on failure. This function incrementsthe remote processor's refcount, so always use rproc_put() todecrement it back once rproc isn't needed anymore.Typical usage=============:: #include <linux/remoteproc.h> /* in case we were given a valid 'rproc' handle */ int dummy_rproc_example(struct rproc *my_rproc) { int ret; /* let's power on and boot our remote processor */ ret = rproc_boot(my_rproc); if (ret) {