Re: [PATCH v1 1/2] arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] ML stream IDs are assigned to the wrong device node (`remoteproc_adsp`), causing Stage 1 SMMU translation faults when the DSP accesses CMA memory mapped by `q6apmdai`.
- [Medium] Adding the 'memory-region' property to the q6apmdai node violates the device tree binding schema.
- [Medium] Adding multiple stream IDs to the `iommus` property of `remoteproc_adsp` violates the `maxItems: 1` constraint inherited from the PAS common binding.
- [Low] The reserved-memory node name `qcom,audio-ml` improperly contains a vendor prefix and comma.
--

--- Patch [1]: [PATCH v1 1/2] arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings ---
commit ca6c69a94d584933404e0f4eb77272a1012439df
Author: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>

arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings

This commit adds a 16 MiB CMA region for audio ML offload and assigns it to
the q6apm DAIs node. It also adds new SMMU stream IDs to the remoteproc
ADSP node in the EL2 overlay to allow the DSP to access the buffers without
faulting.

> diff --git a/arch/arm64/boot/dts/qcom/lemans-el2.dtso b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> index 621ad930cf547..5b477346ef908 100644
> --- a/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> +++ b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> @@ -19,7 +19,9 @@ &iris {
>  };
>  
>  &remoteproc_adsp {
> -	iommus = <&apps_smmu 0x3000 0x0>;
> +	iommus = <&apps_smmu 0x3000 0x0>,
> +		<&apps_smmu 0x3060 0x9>,
> +		<&apps_smmu 0x3062 0x1>;

[Severity: Medium]
The common PAS schema for the adsp node 
(Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml)
restricts the iommus property to maxItems: 1. Does adding three items
here cause dtbs_check to fail?

[Severity: High]
Will placing the ML stream IDs on the remoteproc_adsp node result in SMMU
translation faults when the DSP accesses the CMA memory?

Because the memory-region is wired to the q6apmdai device later in this
patch, the ALSA driver will map the DMA buffer into q6apmdai's IOMMU
domain. However, remoteproc_adsp is a distinct platform device with its
own domain. If the DSP performs transactions using stream IDs 0x3060 and
0x3062, they will be translated by the remoteproc_adsp domain which lacks
the mappings for the CMA buffer.

>  };
>  
>  &remoteproc_cdsp0 {

[ ... ]

> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 3b0539e27b519..0605651137846 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -624,6 +624,14 @@ reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		audio_cma_mem: qcom,audio-ml {

[Severity: Low]
The dtschema for reserved-memory nodes enforces a regex pattern that does
not permit commas (^[a-z0-9-]+(@[0-9a-f]+)?$). Could this vendor prefix and
comma in the node name trigger a dtc node-name-has-comma warning?

> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
> +			reusable;
> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x1000000>;
> +		};
> +

[ ... ]

> @@ -8134,6 +8142,7 @@ q6apmbedai: bedais {
>  						q6apmdai: dais {
>  							compatible = "qcom,q6apm-dais";
>  							iommus = <&apps_smmu 0x3001 0x0>;
> +							memory-region = <&audio_cma_mem>;

[Severity: Medium]
Does the qcom,q6apm-dai binding allow the memory-region property?

Running dtbs_check might flag this as an error because the schema for
Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml sets
additionalProperties: false and doesn't explicitly define memory-region.

>  						};
>  					};
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716151854.3041914-1-pratyush.meduri@oss.qualcomm.com?part=1