On 22/02/2019 14:48, Pierre-Louis Bossart wrote:
drivers\rpmsg\rpmsg_internal.h) but keep the upper layer API, qcomm utilize this for glink and smd actually.
That's interesting. Can anyone at Qualcomm/Linaro point to actual examples of the implementation, so that we get a better picture of the split between 'upper layer API' and 'custom mechanism'?
Here is an example of Qualcomm Audio Hexagon DSP :
Remoteproc driver to start dsp is at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Which registers rpmsg channels based of glink or SMD transport once dsp is booted at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... and few other files in drivers/rpmsg/
This rpmsg driver driver will create and destroy endpoints/edges/channels/services based on dsp services and dsp notifications. These notifications are passed to service drivers via rpmsg device driver model.
One example of audio service driver is:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
and the audio drivers are at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/soun...
An example Device Tree of audio and DSP compute offload would look like this:
adsp-pil { compatible = "qcom,msm8996-adsp-pil"; smd-edge { label = "lpass"; mboxes = <&apcs_glb 8>; qcom,smd-edge = <1>; qcom,remote-pid = <2>;
apr { compatible = "qcom,apr-v2"; qcom,smd-channels = "apr_audio_svc"; ... };
fastrpc { qcom,smd-channels = "fastrpcsmd-apps-dsp"; compatible = "qcom,fastrpc"; ... } ... }; };
thanks, srini