[PATCH v2 0/3] arm64: dts: qcom: enable audio ML offload

[PATCH v2 0/3] arm64: dts: qcom: enable audio ML offload

[Pratyush Meduri]

The audio ML offload use case on Lemans requires a dedicated contiguous
memory region shared with the audio DSP/SPF as well as corresponding
SMMU stream ID mappings under the EL2 configuration.

This series adds a dedicated CMA pool for audio ML buffers and
associates it with the q6apm audio subsystem. It also updates the ADSP
SMMU configuration in the EL2 overlay to include the ML-related stream
IDs required for DMA transactions during model offload.

Without these changes, audio ML workloads may fail due to unavailable
contiguous memory or SMMU faults caused by unmapped stream IDs.

changes in v2:
 - fixed dt binding issue for iommu.
 - v1 link: https://lore.kernel.org/all/20260716151854.3041914-1-pratyush.meduri@oss.qualcomm.com/

Pratyush Meduri (3):
  dt-bindings: remoteproc: qcom,pas-common: allow up to 3 iommus
  arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU
    mappings
  arm64: dts: qcom: monaco: enable audio ML offload memory and SMMU
    mappings

 .../devicetree/bindings/remoteproc/qcom,pas-common.yaml  | 3 ++-
 arch/arm64/boot/dts/qcom/lemans-el2.dtso                 | 4 +++-
 arch/arm64/boot/dts/qcom/lemans.dtsi                     | 9 +++++++++
 arch/arm64/boot/dts/qcom/monaco-el2.dtso                 | 4 +++-
 arch/arm64/boot/dts/qcom/monaco.dtsi                     | 9 +++++++++
 5 files changed, 26 insertions(+), 3 deletions(-)


base-commit: b8809969e1d7a591e0f49dd464a5d04b3cf02ab1
-- 
2.34.1

[PATCH v2 1/3] dt-bindings: remoteproc: qcom,pas-common: allow up to 3 iommus

[Pratyush Meduri]

The ADSP PAS on several Qualcomm SoCs (e.g. SA8775P/lemans, QCS8300,
Monaco) needs more than a single SMMU stream ID for the audio ML
(machine-learning) offload use case. In addition to the primary
ADSP stream ID, the DSP/SPF issues DMA transactions through extra
stream IDs that are not covered by the existing single-entry mapping.

Relax the iommus constraint to allow between 1 and 3 entries so the
additional ML offload stream IDs can be described, fixing dtb_check
schema violations on device trees that add them.

Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
---
 .../devicetree/bindings/remoteproc/qcom,pas-common.yaml        | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
index 11faf655f530..fb656bda8527 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -33,7 +33,8 @@ properties:
     maxItems: 6
 
   iommus:
-    maxItems: 1
+    minItems: 1
+    maxItems: 3
 
   power-domains:
     minItems: 1
-- 
2.34.1

[PATCH v2 2/3] arm64: dts: qcom: lemans: enable audio ML offload memory and SMMU mappings

[Pratyush Meduri]

The audio ML (machine-learning) offload use case requires a contiguous,
physically addressable buffer shared with the audio DSP/SPF, and issues
DMA transactions through additional SMMU stream IDs that are not
covered by the existing ADSP mapping.

Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB
aligned) and wire it to the q6apm DAIs node via memory-region. A
dedicated pool guarantees the alignment and contiguity the DSP expects
and isolates these allocations from the default CMA region.

Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully
enforcing, so the ML transactions are otherwise blocked and faulted:

 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3060
 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x3062

Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the
remoteproc_adsp iommus property in the EL2 overlay so these buffers are
translated by the SMMU instead of being rejected.

Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans-el2.dtso | 4 +++-
 arch/arm64/boot/dts/qcom/lemans.dtsi     | 9 +++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/lemans-el2.dtso b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
index 621ad930cf54..5b477346ef90 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>;
 };
 
 &remoteproc_cdsp0 {
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 3b0539e27b51..060565113784 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 {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
+			reusable;
+			alignment = <0x0 0x400000>;
+			size = <0x0 0x1000000>;
+		};
+
 		sail_ss_mem: sail-ss@80000000 {
 			reg = <0x0 0x80000000 0x0 0x10000000>;
 			no-map;
@@ -8134,6 +8142,7 @@ q6apmbedai: bedais {
 						q6apmdai: dais {
 							compatible = "qcom,q6apm-dais";
 							iommus = <&apps_smmu 0x3001 0x0>;
+							memory-region = <&audio_cma_mem>;
 						};
 					};
 
-- 
2.34.1

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

[sashiko-bot]

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

[PATCH v2 3/3] arm64: dts: qcom: monaco: enable audio ML offload memory and SMMU mappings

[Pratyush Meduri]

The audio ML (machine-learning) offload use case requires a contiguous,
physically addressable buffer shared with the audio DSP/SPF, and issues
DMA transactions through additional SMMU stream IDs that are not
covered by the existing ADSP mapping.

Add a dedicated reusable shared-dma-pool CMA region (16 MiB, 4 MiB
aligned) and wire it to the q6apm DAIs node via memory-region. A
dedicated pool guarantees the alignment and contiguity the DSP expects
and isolates these allocations from the default CMA region.

Under the EL2 (Gunyah/hypervisor) configuration the SMMU is fully
enforcing, so the ML transactions are otherwise blocked and faulted:

 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2060
 arm-smmu 15000000.iommu: Blocked unknown Stream ID 0x2062

Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the
remoteproc_adsp iommus property in the EL2 overlay so these buffers are
translated by the SMMU instead of being rejected.

Signed-off-by: Pratyush Meduri <pratyush.meduri@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco-el2.dtso | 4 +++-
 arch/arm64/boot/dts/qcom/monaco.dtsi     | 9 +++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/monaco-el2.dtso b/arch/arm64/boot/dts/qcom/monaco-el2.dtso
index a7e3270f8609..97bb8287cec3 100644
--- a/arch/arm64/boot/dts/qcom/monaco-el2.dtso
+++ b/arch/arm64/boot/dts/qcom/monaco-el2.dtso
@@ -17,7 +17,9 @@ &iris {
 };
 
 &remoteproc_adsp {
-	iommus = <&apps_smmu 0x2000 0x0>;
+	iommus = <&apps_smmu 0x2000 0x0>,
+		<&apps_smmu 0x2060 0x9>,
+		<&apps_smmu 0x2062 0x1>;
 };
 
 &remoteproc_cdsp {
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 64fc0d592282..d971c0ea1b30 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -729,6 +729,14 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
+		audio_cma_mem: qcom,audio-ml {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
+			reusable;
+			alignment = <0x0 0x400000>;
+			size = <0x0 0x1000000>;
+		};
+
 		aop_image_mem: aop-image-region@90800000 {
 			reg = <0x0 0x90800000 0x0 0x60000>;
 			no-map;
@@ -2844,6 +2852,7 @@ q6apmbedai: bedais {
 						q6apmdai: dais {
 							compatible = "qcom,q6apm-dais";
 							iommus = <&apps_smmu 0x2001 0x0>;
+							memory-region = <&audio_cma_mem>;
 						};
 					};
 
-- 
2.34.1

Re: [PATCH v2 3/3] arm64: dts: qcom: monaco: enable audio ML offload memory and SMMU mappings

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The ML-related SMMU stream IDs are added to a different device's IOMMU domain (remoteproc_adsp) than the device mapping the CMA buffer (q6apmdai), leading to Stage 1 Translation Faults.
- [Medium] The commit message incorrectly documents the Stream IDs being added as 0x3060 and 0x3062, while the code adds 0x2060 and 0x2062.
- [Low] The newly added reserved-memory node uses a vendor prefix and comma (`qcom,audio-ml`), which violates standard DT node naming guidelines.

Pre-existing issues:
- [High] The `q6apmdai` driver does not initialize the DT `memory-region` property, rendering the devicetree addition inert and causing allocations to fall back to the default allocator.
--

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

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

The audio ML (machine-learning) offload use case requires a contiguous,
physically addressable buffer shared with the audio DSP/SPF, and issues
DMA transactions through additional SMMU stream IDs that are not
covered by the existing ADSP mapping.

[ ... ]

> Add the ML-related stream IDs (0x3060 mask 0x9, 0x3062 mask 0x1) to the
> remoteproc_adsp iommus property in the EL2 overlay so these buffers are
> translated by the SMMU instead of being rejected.

[Severity: Medium]
The commit message documents adding stream IDs 0x3060 and 0x3062, but the code
adds 0x2060 and 0x2062. Is this a typo in the commit message?

> diff --git a/arch/arm64/boot/dts/qcom/monaco-el2.dtso b/arch/arm64/boot/dts/qcom/monaco-el2.dtso
> index a7e3270f86090..97bb8287cec33 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-el2.dtso
> +++ b/arch/arm64/boot/dts/qcom/monaco-el2.dtso
> @@ -17,7 +17,9 @@ &iris {
>  };
>  
>  &remoteproc_adsp {
> -	iommus = <&apps_smmu 0x2000 0x0>;
> +	iommus = <&apps_smmu 0x2000 0x0>,
> +		<&apps_smmu 0x2060 0x9>,
> +		<&apps_smmu 0x2062 0x1>;
>  };

[Severity: High]
Does adding the ML-related stream IDs to the remoteproc_adsp node result in
Stage 1 Translation Faults?

The memory-region is assigned to the q6apmdai device (which uses stream ID
0x2001) in monaco.dtsi. When q6apmdai allocates and DMA-maps the memory, the
mapping is created in the IOMMU domain associated with 0x2001. 

By adding 0x2060 and 0x2062 to remoteproc_adsp (which uses 0x2000), the Linux
arm-smmu driver places these stream IDs into a different IOMMU domain than the
one holding the ML memory mapping. Should these stream IDs be added to the
q6apmdai node instead so they share the same IOMMU domain?

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 64fc0d592282c..d971c0ea1b302 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -729,6 +729,14 @@ reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		audio_cma_mem: qcom,audio-ml {

[Severity: Low]
Does this node name violate Devicetree naming conventions? Node names should
typically be generic and avoid vendor prefixes and commas, which are reserved
for compatible strings.

> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
> +			reusable;
> +			alignment = <0x0 0x400000>;
> +			size = <0x0 0x1000000>;
> +		};
> +
[ ... ]
> @@ -2844,6 +2852,7 @@ q6apmbedai: bedais {
>  						q6apmdai: dais {
>  							compatible = "qcom,q6apm-dais";
>  							iommus = <&apps_smmu 0x2001 0x0>;
> +							memory-region = <&audio_cma_mem>;
>  						};

[Severity: High]
This isn't a bug introduced by this patch, but will this memory-region
assignment be ignored by the q6apmdai driver?

Looking at q6apm_dai_probe() in sound/soc/qcom/qdsp6/q6apm-dai.c:

	rc = of_parse_phandle_with_fixed_args(node, "iommus", 1, 0, &args);
	if (rc < 0)
		pdata->sid = -1;
	else
		pdata->sid = args.args[0] & SID_MASK_DEFAULT;

	dev_set_drvdata(dev, pdata);

	return devm_snd_soc_register_component(dev, &q6apm_fe_dai_component, NULL, 0);

The driver probe function does not call of_reserved_mem_device_init(). For a
shared-dma-pool, the driver must explicitly initialize it. Without this call,
the driver dev->cma_area remains unconfigured and memory allocations will
silently fall back to the default system CMA pool, defeating the purpose of
adding this dedicated 16MiB region.

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