Re: [PATCH v1 1/2] arm64: dts: qcom: sm6150: Add gpr node

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

On 10/24/25 4:37 AM, Le Qi wrote:
> Add GPR(Generic Pack router) node along with
> APM(Audio Process Manager) and PRM(Proxy resource
> Manager) audio services.

This is a really weird
way of breaking your message that makes
it difficult to read

(stick to something more like 72 characters, please)

> 
> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/sm6150.dtsi | 36 ++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm6150.dtsi b/arch/arm64/boot/dts/qcom/sm6150.dtsi
> index 3d2a1cb02b62..ec244c47983e 100644
> --- a/arch/arm64/boot/dts/qcom/sm6150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6150.dtsi
> @@ -16,6 +16,7 @@
>  #include <dt-bindings/power/qcom-rpmpd.h>
>  #include <dt-bindings/power/qcom,rpmhpd.h>
>  #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> +#include <dt-bindings/soc/qcom,gpr.h>
>  
>  / {
>  	interrupt-parent = <&intc>;
> @@ -4246,6 +4247,41 @@ compute-cb@6 {
>  						dma-coherent;
>  					};
>  				};
> +
> +				gpr: gpr {
> +					compatible = "qcom,gpr";
> +					qcom,glink-channels = "adsp_apps";
> +					qcom,domain = <GPR_DOMAIN_ID_ADSP>;
> +					qcom,intents = <512 20>;
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					q6apm: service@1 {
> +						compatible = "qcom,q6apm";
> +						reg = <GPR_APM_MODULE_IID>;
> +						#sound-dai-cells = <0>;
> +
> +						q6apmbedai: bedais {
> +							compatible = "qcom,q6apm-lpass-dais";
> +							#sound-dai-cells = <1>;
> +						};
> +
> +						q6apmdai: dais {
> +							compatible = "qcom,q6apm-dais";
> +							iommus = <&apps_smmu 0x1721 0x0>;

I see that the documentation mentions a mask of 0x0 (like you did
here), but downstream does something funny here:

iommus = <&apps_smmu 0x1721 0x0>;
qcom,smmu-sid-mask = /bits/ 64 <0xf>;

with the latter value being consumed by the driver manually and when
it binds some sort of DMA_BUFs, the effective SID (ID & mask -- notice
there's no bitflipping of the mask part here unlike in the SMMU driver)
is prepended to the address:

smmu->pa |= ((sid & mask) << 32);

We can then check that the SMMU driver reads the SMR mask as a 16b field,
meaning the result is (sid & 0xffff) and not (sid & 0xf).. 

If we take the hardcoded-downstream mask and compare it with the HSR,
we can notice that all the streams in the 0x172X range correspond to
LPASS_ADSP, so perhaps it's a design choice that the DSP end only cares
about the least significant digit

TLDR this seems to be all OK

Konrad