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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/16/26 5:18 PM, Pratyush Meduri wrote:
> 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.

[...]

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

1. Does the Gunyah setup need any updates?
2. Are the existing SIDs wrong? Aren't they just used for other offloads
   usecases?
>  };
>  
>  &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 {

Node names *must not* contain commas and should be generic

> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;

Is the last byte forbidden on purpose?

Konrad