[PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Vishnu Santhosh]

Add required nodes to enable the upstream BAM-DMUX WWAN driver on
Qualcomm Shikra SoC.

The SMSM (Shared Memory State Machine) node provides the power
control signaling between the AP and modem for BAM-DMUX. The
BAM DMA controller node describes the A2 modem BAM hardware as a
standard DMA controller. The BAM-DMUX node references the DMA
channels and the pc/pc-ack interrupt lines from the modem SMSM
entry for power control signaling.

Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra.dtsi | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..3e59d5f6323c0d857f376316faa26c503e67f6bc 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -17,6 +17,23 @@ / {
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	bam_dmux: bam-dmux {
+		compatible = "qcom,bam-dmux";
+
+		interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
+				      <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
+		interrupt-names = "pc",
+				  "pc-ack";
+
+		qcom,smem-states = <&apps_smsm 1>,
+				   <&apps_smsm 11>;
+		qcom,smem-state-names = "pc",
+					"pc-ack";
+
+		dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
+		dma-names = "tx", "rx";
+	};
+
 	clocks {
 		xo_board: xo-board {
 			compatible = "fixed-clock";
@@ -314,6 +331,28 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
 		};
 	};
 
+	smsm {
+		compatible = "qcom,smsm";
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mboxes = <0>, <&apcs_glb 13>;
+
+		apps_smsm: apps@0 {
+			reg = <0>;
+			#qcom,smem-state-cells = <1>;
+		};
+
+		modem_smsm: modem@1 {
+			reg = <1>;
+			interrupts = <GIC_SPI 69 IRQ_TYPE_EDGE_RISING 0>;
+
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+
 	soc: soc@0 {
 		compatible = "simple-bus";
 
@@ -640,6 +679,18 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
 			};
 		};
 
+		bam_dmux_dma: dma-controller@6044000 {
+			compatible = "qcom,bam-v1.7.0";
+			reg = <0x0 0x06044000 0x0 0x19000>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
+			#dma-cells = <1>;
+			qcom,ee = <0>;
+
+			num-channels = <6>;
+			qcom,num-ees = <1>;
+			qcom,powered-remotely;
+		};
+
 		sram@c11e000 {
 			compatible = "qcom,shikra-imem", "mmio-sram";
 			reg = <0x0 0x0c11e000 0x0 0x1000>;

---
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
change-id: 20260603-qcom-shikra-dts-bam-dmux-7fdcbb6fb662
prerequisite-message-id: <20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com>
prerequisite-patch-id: 3a689e8dda5fd2755b689d94d095806b3f2e6eed
prerequisite-patch-id: 2acc300a68ed8c5364fb5f2f7d28fc0d56ab07bf
prerequisite-patch-id: 2357cac636e019eaf14d6a493a1c72bca56fe405
prerequisite-patch-id: 2885f299e711582da312ca9d13983d296a3dd5dc
prerequisite-patch-id: 91af5f3c01e766a53ce8de69aa21847a2d6bbbf8

Best regards,
-- 
Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Stephan Gerhold]

On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> Add required nodes to enable the upstream BAM-DMUX WWAN driver on
> Qualcomm Shikra SoC.
> 
> The SMSM (Shared Memory State Machine) node provides the power
> control signaling between the AP and modem for BAM-DMUX. The
> BAM DMA controller node describes the A2 modem BAM hardware as a
> standard DMA controller. The BAM-DMUX node references the DMA
> channels and the pc/pc-ack interrupt lines from the modem SMSM
> entry for power control signaling.
> 
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

I'm quite surprised to see this 15+ years(?) old hardware block being
brought back to a new SoC. Is Shikra not using IPA?

> ---
>  arch/arm64/boot/dts/qcom/shikra.dtsi | 51 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..3e59d5f6323c0d857f376316faa26c503e67f6bc 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -17,6 +17,23 @@ / {
>  	#address-cells = <2>;
>  	#size-cells = <2>;
>  
> +	bam_dmux: bam-dmux {
> +		compatible = "qcom,bam-dmux";
> +
> +		interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
> +				      <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
> +		interrupt-names = "pc",
> +				  "pc-ack";
> +
> +		qcom,smem-states = <&apps_smsm 1>,
> +				   <&apps_smsm 11>;
> +		qcom,smem-state-names = "pc",
> +					"pc-ack";
> +
> +		dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> +		dma-names = "tx", "rx";
> +	};

This should be a child node of the modem remoteproc. See msm8916.dtsi
for example.

> +
>  	clocks {
>  		xo_board: xo-board {
>  			compatible = "fixed-clock";
> @@ -314,6 +331,28 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
>  		};
>  	};
>  
> +	smsm {
> +		compatible = "qcom,smsm";
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		mboxes = <0>, <&apcs_glb 13>;
> +
> +		apps_smsm: apps@0 {
> +			reg = <0>;
> +			#qcom,smem-state-cells = <1>;
> +		};
> +
> +		modem_smsm: modem@1 {
> +			reg = <1>;
> +			interrupts = <GIC_SPI 69 IRQ_TYPE_EDGE_RISING 0>;
> +
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +	};
> +
>  	soc: soc@0 {
>  		compatible = "simple-bus";
>  
> @@ -640,6 +679,18 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
>  			};
>  		};
>  
> +		bam_dmux_dma: dma-controller@6044000 {
> +			compatible = "qcom,bam-v1.7.0";
> +			reg = <0x0 0x06044000 0x0 0x19000>;
> +			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
> +			#dma-cells = <1>;
> +			qcom,ee = <0>;
> +
> +			num-channels = <6>;
> +			qcom,num-ees = <1>;
> +			qcom,powered-remotely;
> +		};
> +
>  		sram@c11e000 {
>  			compatible = "qcom,shikra-imem", "mmio-sram";
>  			reg = <0x0 0x0c11e000 0x0 0x1000>;
> 
> ---
> base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
> change-id: 20260603-qcom-shikra-dts-bam-dmux-7fdcbb6fb662
> prerequisite-message-id: <20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com>
> prerequisite-patch-id: 3a689e8dda5fd2755b689d94d095806b3f2e6eed
> prerequisite-patch-id: 2acc300a68ed8c5364fb5f2f7d28fc0d56ab07bf
> prerequisite-patch-id: 2357cac636e019eaf14d6a493a1c72bca56fe405
> prerequisite-patch-id: 2885f299e711582da312ca9d13983d296a3dd5dc
> prerequisite-patch-id: 91af5f3c01e766a53ce8de69aa21847a2d6bbbf8
> 

If the DT isn't merged yet, you can also just squash that into the
existing series that adds the modem remoteproc.

Thanks,
Stephan

Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Konrad Dybcio]

On 6/11/26 10:55 AM, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
>> Add required nodes to enable the upstream BAM-DMUX WWAN driver on
>> Qualcomm Shikra SoC.
>>
>> The SMSM (Shared Memory State Machine) node provides the power
>> control signaling between the AP and modem for BAM-DMUX. The
>> BAM DMA controller node describes the A2 modem BAM hardware as a
>> standard DMA controller. The BAM-DMUX node references the DMA
>> channels and the pc/pc-ack interrupt lines from the modem SMSM
>> entry for power control signaling.
>>
>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> 
> I'm quite surprised to see this 15+ years(?) old hardware block being
> brought back to a new SoC. Is Shikra not using IPA?

That's correct.

Konrad

Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Stephan Gerhold]

On Thu, Jun 11, 2026 at 11:10:51AM +0200, Konrad Dybcio wrote:
> On 6/11/26 10:55 AM, Stephan Gerhold wrote:
> > On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> >> Add required nodes to enable the upstream BAM-DMUX WWAN driver on
> >> Qualcomm Shikra SoC.
> >>
> >> The SMSM (Shared Memory State Machine) node provides the power
> >> control signaling between the AP and modem for BAM-DMUX. The
> >> BAM DMA controller node describes the A2 modem BAM hardware as a
> >> standard DMA controller. The BAM-DMUX node references the DMA
> >> channels and the pc/pc-ack interrupt lines from the modem SMSM
> >> entry for power control signaling.
> >>
> >> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> > 
> > I'm quite surprised to see this 15+ years(?) old hardware block being
> > brought back to a new SoC. Is Shikra not using IPA?
> 
> That's correct.
> 

Ok, thanks for the confirmation. It's nice to see my driver running on
some new SoCs 6 years later. :-)

Thanks,
Stephan

Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Vishnu Santhosh]

On 11-06-2026 02:25 pm, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
>> +	bam_dmux: bam-dmux {
>> +		compatible = "qcom,bam-dmux";
>> +
>> +		interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
>> +				      <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
>> +		interrupt-names = "pc",
>> +				  "pc-ack";
>> +
>> +		qcom,smem-states = <&apps_smsm 1>,
>> +				   <&apps_smsm 11>;
>> +		qcom,smem-state-names = "pc",
>> +					"pc-ack";
>> +
>> +		dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
>> +		dma-names = "tx", "rx";
>> +	};
> This should be a child node of the modem remoteproc. See msm8916.dtsi
> for example.

Thanks for the context! We actually referenced msm8916.dtsi during 
bring-up and initially placed bam-dmux as a
remoteproc child. We then hit the issue that the driver was not probing 
at all. After some digging, we realized
that qcom_q6v5_mss.c (used by msm8916) explicitly calls 
of_platform_device_create() for its qcom,bam-dmux child,
but qcom_q6v5_pas.c which Shikra uses has no such logic, so the platform 
device was never created.

There was a prior attempt to fix this generically by adding 
of_platform_populate() to qcom_q6v5.c
(https://lore.kernel.org/all/20251223123227.1317244-3-gaurav.kohli@oss.qualcomm.com/), 
but it was blocked
because GLINK/SMD edge child nodes would also get spurious platform 
devices registered for them.
That series remains unresolved at v1.

Since your driver already manages modem lifecycle independently via SMSM 
state bits without remoteproc dependency,
we moved it to the root level where of_platform_populate() picks it up 
at boot, and everything worked.

Would love to get your suggestion on whether this approach is welcomed, 
since it needs zero driver changes.

Thanks,
Vishnu

Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Stephan Gerhold]

On Thu, Jun 11, 2026 at 09:31:06PM +0530, Vishnu Santhosh wrote:
> On 11-06-2026 02:25 pm, Stephan Gerhold wrote:
> > On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> > > +	bam_dmux: bam-dmux {
> > > +		compatible = "qcom,bam-dmux";
> > > +
> > > +		interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
> > > +				      <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
> > > +		interrupt-names = "pc",
> > > +				  "pc-ack";
> > > +
> > > +		qcom,smem-states = <&apps_smsm 1>,
> > > +				   <&apps_smsm 11>;
> > > +		qcom,smem-state-names = "pc",
> > > +					"pc-ack";
> > > +
> > > +		dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> > > +		dma-names = "tx", "rx";
> > > +	};
> > This should be a child node of the modem remoteproc. See msm8916.dtsi
> > for example.
> 
> Thanks for the context! We actually referenced msm8916.dtsi during bring-up
> and initially placed bam-dmux as a
> remoteproc child. We then hit the issue that the driver was not probing at
> all. After some digging, we realized
> that qcom_q6v5_mss.c (used by msm8916) explicitly calls
> of_platform_device_create() for its qcom,bam-dmux child,
> but qcom_q6v5_pas.c which Shikra uses has no such logic, so the platform
> device was never created.
> 
> There was a prior attempt to fix this generically by adding
> of_platform_populate() to qcom_q6v5.c
> (https://lore.kernel.org/all/20251223123227.1317244-3-gaurav.kohli@oss.qualcomm.com/),
> but it was blocked
> because GLINK/SMD edge child nodes would also get spurious platform devices
> registered for them.
> That series remains unresolved at v1.
> 
> Since your driver already manages modem lifecycle independently via SMSM
> state bits without remoteproc dependency,
> we moved it to the root level where of_platform_populate() picks it up at
> boot, and everything worked.
> 
> Would love to get your suggestion on whether this approach is welcomed,
> since it needs zero driver changes.
> 

Adding the bam-dmux node top-level makes it impossible for userspace to
associate it with a remoteproc (for this purpose: the "modem"). If you
add it below the remoteproc the udev/sysfs path will include the
remoteproc and you can tell that the network interfaces exposed by
bam_dmux belong to that remoteproc.

As you noticed, having a generic of_platform_populate() for remoteproc
nodes is problematic, because usually subnodes are remoteproc subdevs.
Also, the cooling device use case in the thread you linked doesn't have
any resources attached, so the root complaint there was that you don't
need a separate subnode at all.

I would just replicate the special qcom,bam-dmux logic inside
qcom_q6v5_pas.c. I think the motivation for BAM-DMUX explained in commit
59983c74fc42 ("remoteproc: qcom_q6v5_mss: Create platform device for
BAM-DMUX") is still valid. Conceptually, BAM-DMUX is a subdevice of the
modem remoteproc, since the remoteproc is responsible for powering the
BAM-DMUX hardware on and off. The fact that BAM-DMUX is not a remoteproc
subdev in Linux is more an implementation detail of the current Linux
driver. This is independent from the model in the device tree.

Thanks,
Stephan