Re: [PATCH v2 1/3] arm64: dts: qcom: eliza: Describe the CDSP remoteproc

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `remoteproc_cdsp` node lacks the `glink-edge` subnode required for inter-processor communication.
--

--- Patch [1]: [PATCH v2 1/3] arm64: dts: qcom: eliza: Describe the CDSP remoteproc ---
commit 0d8a8296d1e008af4feca584273c5028b5ea34a2
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>

arm64: dts: qcom: eliza: Describe the CDSP remoteproc

This commit introduces the CDSP remoteproc and its related SMP2P node.
It provisions the device tree nodes, interrupts, clocks, and power
domains necessary for the DSP.

> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
[ ... ]
> @@ -3737,6 +3761,46 @@ nsp_noc: interconnect@320c0000 {
>  			qcom,bcm-voters = <&apps_bcm_voter>;
>  			#interconnect-cells = <2>;
>  		};
> +
> +		remoteproc_cdsp: remoteproc@32300000 {
> +			compatible = "qcom,eliza-cdsp-pas";
> +			reg = <0x0 0x32300000 0x0 0x10000>;

[Severity: Medium]
Does this node also need a glink-edge subnode?

Without the glink-edge subnode and a fastrpc child, it appears the
application processor might not be able to establish GLINK/IPCC message
channels with the CDSP. Will this prevent the DSP from receiving
workloads from the host when the node is eventually enabled?

> +
> +			interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
> +					      <&smp2p_cdsp_in 0 IRQ_TYPE_EDGE_RISING>,
> +					      <&smp2p_cdsp_in 1 IRQ_TYPE_EDGE_RISING>,
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-dts-qcom-eliza-add-cdsp-v2-0-e1e52bfb3c12@oss.qualcomm.com?part=1