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

[Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>]

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@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

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