Re: [PATCH v2 2/3] 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 2 potential issue(s) to consider:
- [High] IOMMU Domain Mismatch causing SMMU Translation Faults
- [Low] Device Tree Naming Anti-pattern for reserved-memory node
--

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

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

The audio ML offload use case requires a contiguous buffer shared with the
audio DSP, issuing DMA transactions through additional SMMU stream IDs. This
adds a dedicated shared-dma-pool CMA region wired to q6apm DAIs and maps
the ML stream IDs to the EL2 overlay remoteproc_adsp iommus property.

> 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>;
>  };

[ ... ]

> 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]
This isn't a bug, but does this node name violate Device Tree naming
conventions? 

Node names are typically generic and shouldn't contain vendor prefixes or
commas unless they match the first compatible string exactly.

Could this be renamed to something like audio-ml-cma or audio-ml-mempool
instead?

> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
> +			reusable;
> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x1000000>;
> +		};
> +
>  		sail_ss_mem: sail-ss@80000000 {

[ ... ]

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

[Severity: High]
Will the ML engine actually be able to access this memory without triggering
SMMU translation faults?

The CMA memory region (audio_cma_mem) is assigned here to the q6apmdai
device. Consequently, allocations from this pool are mapped exclusively into
the IOMMU domain associated with q6apmdai (stream ID 0x3001).

However, the ML stream IDs (0x3060 and 0x3062) were assigned to the
remoteproc_adsp device earlier in lemans-el2.dtso:

&remoteproc_adsp {
        iommus = <&apps_smmu 0x3000 0x0>,
                 <&apps_smmu 0x3060 0x9>,
                 <&apps_smmu 0x3062 0x1>;
};

Since separate platform devices with distinct iommus properties are placed
into separate IOMMU groups and domains, won't the SMMU fail to look up the
CMA memory mappings when the ML engine issues transactions using stream ID
0x3060 or 0x3062?

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