Re: [PATCH v2 1/2] arm64: dts: qcom: nord: add GPI DMA controller nodes

[Mukesh Savaliya]

Thanks Konrad, Bartosz !

On 9/23/2026 6:10 PM, Konrad Dybcio wrote:
> On 9/22/26 10:24 AM, Bartosz Golaszewski wrote:
> > On Tue, 22 Sep 2026 07:34:25 +0200, Mukesh Savaliya
> > <mukesh.savaliya@xxxxxxxxxxxxxxxx> said:
> > > On 9/21/2026 8:16 PM, Bartosz Golaszewski wrote:
> > > [...]
> > >
> > > > +#include <dt-bindings/dma/qcom-gpi.h>
> > > >    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > >
> > > >    / {
> > > > @@ -909,6 +910,28 @@ soc: soc@0 {
> > > >    		dma-ranges = <0 0 0 0 0x10 0>;
> > > >    		ranges = <0 0 0 0 0x10 0>;
> > > >
> > > > +		gpi_dma2: dma-controller@800000 {
> > > > +			compatible = "qcom,nord-gpi-dma", "qcom,sm6350-gpi-dma";
> > > > +			reg = <0x0 0x00800000 0x0 0x60000>;
> > > > +			#dma-cells = <3>;
> > > > +			interrupts = <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 589 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 590 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 591 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 592 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 593 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 594 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 595 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 596 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 597 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>,
> > > > +				     <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
> > > > +			dma-channels = <12>;
> > > > +			dma-channel-mask = <0xfff>;
> > > > +			iommus = <&apps_smmu_0 0x15b6 0x0>;
> > > > +			status = "disabled";
> > >
> > > we should be keeping GPI node default enabled similar to common QUPv3
> > > wrapper node.
> > > status = "ok" for all the nodes.
> >
> > The pattern across Qualcomm platforms seems to disable the GPI DMA nodes at
> > SoC-level and only enable them at board-level.
>
> For no reason - the DMA engines may be reserved through TZ config,
> but for the past (high) N years that hasn't been the case

There is a reason to reserve this from TZ. Some use cases require GPI to 
be available during early boot, before Linux is up and running, which 
necessitates keeping the GPI instance enabled.

Also, GPII is allocated per SE, while the GPI instance itself is shared 
across all SEs within a QUP. Given that a QUP typically contains eight 
SEs, it is likely that at least one SE will require GPI operation.

For that reason, my preference is to keep the GPI node enabled by 
default. However, if there is a strong preference to make this 
board-specific and enable it only where required, I can work with that 
approach as well.

I think it would be better to align on the expected default behavior 
now, rather than revisiting it later once additional users start 
depending on it.

> Konrad