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

[Le Qi]

On 10/24/2025 4:13 PM, Konrad Dybcio wrote:
> 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)

Thanks, will modify this in next patch.

> > Signed-off-by: Le Qi <le.qi@xxxxxxxxxxxxxxxx>
> > ---
> >   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

Thank you so much for the detailed explanation.

--
Thx and BRs,
Le Qi