今更感はとてもありますが、リモートで作業することが増え、機械学習などの操作をリモートサーバで行うことが増えました。
理由は自分の持っているノートpcだととてもじゃないけどスペックが足りないからです。
google colab を使うのももちろんいいのですが、長い時間操作しないとタイムアウトになったり、使えるGPUの性能も限られていたりしますしね。
Modern SoCs typically have heterogeneous remote processor devices in asymmetric multiprocessing (AMP) configurations, which may be running different instances of 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 SMP configuration, 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 to control (power on, load firmware, power off) those remote processors while abstracting the hardware differences, so the entire driver doesn't need to be duplicated. In addition, this framework also adds rpmsg virtio devices for remote processors that supports this kind of communication. This way, platform-specific remoteproc drivers only need to provide a few low-level handlers, 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. Firmwares just need to publish what kind of virtio devices do they support, and then remoteproc will add those devices. This makes it possible to reuse the existing virtio drivers with remote processor backends at a minimal development cost.
Returns 0 on success, and an appropriate error value otherwise.
成功した場合、戻り値は0であり、そうでない場合には適切なエラー値が入る。
Note: to use this function you should already have a valid rproc handle. There are several ways to achieve that cleanly (devres, pdata, the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we might also consider using dev_archdata for this).
Power off a remote processor (previously booted with rproc_boot()). In case @rproc is still being used by an additional user(s), then this function will just decrement the power refcount and exit, without really powering off the device.
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.
Find an rproc handle using a device tree phandle. Returns the rproc handle on success, and NULL on failure. This function increments the remote processor's refcount, so always use rproc_put() to decrement it back once rproc isn't needed anymore.
device tree phandleを使ってrpoc handleを探索します。成功した場合にはrpoc handleが、失敗したときにはNULLが帰ります。この関数はremote processorのrefcountを増化させます。rpocが不要となった場合には、rpoc_put()を使って減少させてください。
Typical usage
#include <linux/remoteproc.h>
/* in case we were given a valid 'rproc' handle *//* 有効な`rpoc` handleが得られているケースにおいて */intdummy_rproc_example(structrproc*my_rproc){intret;/* let's power on and boot our remote processor *//* remote processorの電源投入と起動 */ret=rproc_boot(my_rproc);if(ret){/*
* something went wrong. handle it and leave.
*//*
* 何か問題が起きたので、それをハンドリングして離れてください
*/}/*
* our remote processor is now powered on... give it some work
*//*
* remote processorは今、電源投入された、仕事を与えてください。
*//* let's shut it down now *//* 電源切断 */rproc_shutdown(my_rproc);}
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
