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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
