[alsa-devel] [Sound-open-firmware] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core

[Srinivas Kandagatla]

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/drivers/remoteproc/qcom_common.c?h=v5.0-rc8

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/drivers/rpmsg/qcom_glink_smem.c?h=v5.0-rc8 
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/drivers/soc/qcom/apr.c?h=v5.0-rc8

and the audio drivers are at:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/qcom/qdsp6?h=v5.0-rc8

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