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

[Vishnu Santhosh]

On 11-06-2026 10:27 pm, Stephan Gerhold wrote:
> 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@xxxxxxxxxxxxxxxx/),
> > 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

Thanks for the guidance. This makes sense. I'm preparing an update to
incorporate the DT changes and replicate the BAM-DMUX platform device
creation logic in qcom_q6v5_pas.c as suggested.

Thanks,
Vishnu