[PATCH 0/2] Enable BAM-DMUX/WWAN on Qualcomm MSM8916

[PATCH 0/2] Enable BAM-DMUX/WWAN on Qualcomm MSM8916

[Stephan Gerhold]

This series enables using mobile Internet/WWAN on devices based on Qualcomm
MSM8916. The network driver for that was applied earlier today to net-next. [1]

The device tree node of BAM-DMUX does not have any own memory resources.
It just bundles resources from other hardware blocks. It could be added to the
device tree root node, but it logically belongs below the modem remote processor.

To allow adding it there, the qcom_q6v5_mss driver is modified slightly to
populate additional devices from the device tree. Finally, the necessary
nodes are added to the MSM8916 device tree.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=688e075748645b43cf4d55e8fd279f5249699b7a

Stephan Gerhold (2):
  remoteproc: qcom_q6v5_mss: Populate additional devices from DT
  arm64: dts: qcom: msm8916: Add BAM-DMUX for WWAN network interfaces

 arch/arm64/boot/dts/qcom/msm8916.dtsi | 30 +++++++++++++++++++++++++++
 drivers/remoteproc/qcom_q6v5_mss.c    |  7 +++++++
 2 files changed, 37 insertions(+)

-- 
2.34.1

[PATCH 1/2] remoteproc: qcom_q6v5_mss: Populate additional devices from DT

[Stephan Gerhold]

Some devices without own memory resources could be placed anywhere in the
device tree but they logically belong to the modem remote processor. Make
it possible to probe them when defined under the mpss device tree node
by calling of_platform_populate().

This can be used for BAM-DMUX for example, which provides the WWAN network
interfaces on some older Qualcomm SoCs such as MSM8916 or MSM8974.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
 drivers/remoteproc/qcom_q6v5_mss.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 43ea8455546c..69f3d1ebf1f1 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1989,8 +1989,14 @@ static int q6v5_probe(struct platform_device *pdev)
 	if (ret)
 		goto remove_sysmon_subdev;
 
+	ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+	if (ret)
+		goto remove_rproc;
+
 	return 0;
 
+remove_rproc:
+	rproc_del(rproc);
 remove_sysmon_subdev:
 	qcom_remove_sysmon_subdev(qproc->sysmon);
 remove_subdevs:
@@ -2010,6 +2016,7 @@ static int q6v5_remove(struct platform_device *pdev)
 	struct q6v5 *qproc = platform_get_drvdata(pdev);
 	struct rproc *rproc = qproc->rproc;
 
+	of_platform_depopulate(&pdev->dev);
 	rproc_del(rproc);
 
 	qcom_q6v5_deinit(&qproc->q6v5);
-- 
2.34.1

[PATCH 2/2] arm64: dts: qcom: msm8916: Add BAM-DMUX for WWAN network interfaces

[Stephan Gerhold]

The BAM Data Multiplexer provides access to the network data channels
of modems integrated into many older Qualcomm SoCs, including MSM8916.

Add the nodes for the BAM DMA engine and BAM-DMUX to enable using WWAN
on smartphones/tablets based on MSM8916. This should work out of the box
with open-source WWAN userspace such as ModemManager.

The nodes are disabled by default to avoid loading unnecessary drivers
on devices that cannot use BAM-DMUX (e.g. DragonBoard 410c). However,
strictly speaking the nodes could be enabled by default since both the
bam_dma and bam_dmux driver will simply do nothing if the modem does
not announce any BAM-DMUX channels.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 30 +++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c1c42f26b61e..56b6974c01fc 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1309,6 +1309,20 @@ spmi_bus: spmi@200f000 {
 			#interrupt-cells = <4>;
 		};
 
+		bam_dmux_dma: dma-controller@4044000 {
+			compatible = "qcom,bam-v1.7.0";
+			reg = <0x04044000 0x19000>;
+			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			qcom,ee = <0>;
+
+			num-channels = <6>;
+			qcom,num-ees = <1>;
+			qcom,powered-remotely;
+
+			status = "disabled";
+		};
+
 		mpss: remoteproc@4080000 {
 			compatible = "qcom,msm8916-mss-pil", "qcom,q6v5-pil";
 			reg = <0x04080000 0x100>,
@@ -1352,6 +1366,22 @@ mpss {
 				memory-region = <&mpss_mem>;
 			};
 
+			bam_dmux: bam-dmux {
+				compatible = "qcom,bam-dmux";
+
+				interrupt-parent = <&hexagon_smsm>;
+				interrupts = <1 IRQ_TYPE_EDGE_BOTH>, <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";
+
+				status = "disabled";
+			};
+
 			smd-edge {
 				interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
 
-- 
2.34.1

Re: [PATCH 1/2] remoteproc: qcom_q6v5_mss: Populate additional devices from DT

[Bjorn Andersson]

On Mon 29 Nov 07:29 CST 2021, Stephan Gerhold wrote:

> Some devices without own memory resources could be placed anywhere in the
> device tree but they logically belong to the modem remote processor. Make
> it possible to probe them when defined under the mpss device tree node
> by calling of_platform_populate().
> 

This seems reasonable, but other "child devices" of the remoteproc
follows the state of the remoteproc instance. So I'm worried that this
will create an inconsistency in that assumption.

> This can be used for BAM-DMUX for example, which provides the WWAN network
> interfaces on some older Qualcomm SoCs such as MSM8916 or MSM8974.
> 

Is there a technical reason for placing the BAM-DMUX within the modem
remoteproc node? Can we simply move it to / ?

Regards,
Bjorn

> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 43ea8455546c..69f3d1ebf1f1 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -1989,8 +1989,14 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto remove_sysmon_subdev;
>  
> +	ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +	if (ret)
> +		goto remove_rproc;
> +
>  	return 0;
>  
> +remove_rproc:
> +	rproc_del(rproc);
>  remove_sysmon_subdev:
>  	qcom_remove_sysmon_subdev(qproc->sysmon);
>  remove_subdevs:
> @@ -2010,6 +2016,7 @@ static int q6v5_remove(struct platform_device *pdev)
>  	struct q6v5 *qproc = platform_get_drvdata(pdev);
>  	struct rproc *rproc = qproc->rproc;
>  
> +	of_platform_depopulate(&pdev->dev);
>  	rproc_del(rproc);
>  
>  	qcom_q6v5_deinit(&qproc->q6v5);
> -- 
> 2.34.1
> 

Re: [PATCH 1/2] remoteproc: qcom_q6v5_mss: Populate additional devices from DT

[Stephan Gerhold]

On Tue, Nov 30, 2021 at 09:50:06PM -0600, Bjorn Andersson wrote:
> On Mon 29 Nov 07:29 CST 2021, Stephan Gerhold wrote:
> 
> > Some devices without own memory resources could be placed anywhere in the
> > device tree but they logically belong to the modem remote processor. Make
> > it possible to probe them when defined under the mpss device tree node
> > by calling of_platform_populate().
> > 
> 
> This seems reasonable, but other "child devices" of the remoteproc
> follows the state of the remoteproc instance. So I'm worried that this
> will create an inconsistency in that assumption.
> 

On Linux there are two devices managed by qcom_q6v5_mss, the platform
device used by the driver and the actual remoteproc instance that has
the state. The devices that follow the state are children of the
remoteproc instance. I'm creating BAM-DMUX below the platform device.

This is just not represented in the device tree very well since both
platform device and remoteproc instance share the same device tree node.
However, all the state managed nodes are manually managed and do not
have a compatible so it should not cause problems.

> > This can be used for BAM-DMUX for example, which provides the WWAN network
> > interfaces on some older Qualcomm SoCs such as MSM8916 or MSM8974.
> > 
> 
> Is there a technical reason for placing the BAM-DMUX within the modem
> remoteproc node? Can we simply move it to / ?
> 

I had it at / originally and at the moment it would still work there.
I moved it below the remoteproc when the whole "WWAN subsystem"
discussion came up. The goal is to have a common parent device for all
the ports of a WWAN modem.

The way it works is that you give the WWAN subsystem a (parent) device
that represents the modem itself, and then it groups all WWAN ports
below that. The control ports (rpmsg_wwan_ctrl driver) are currently
already created below the modem platform device.

The bam-dmux driver does not integrate with the WWAN subsystem yet
because of some unrelated open problems, but in the future I will likely
need a reference to the modem platform device there as well.

There are other approaches of course (e.g. a phandle to the modem
remoteproc node), but I still think it logically fits best somewhere
below the modem node. If the modem remoteproc is status = "disabled",
it does not make sense to load bam-dmux either etc.

Thanks,
Stephan

> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> > ---
> >  drivers/remoteproc/qcom_q6v5_mss.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> > index 43ea8455546c..69f3d1ebf1f1 100644
> > --- a/drivers/remoteproc/qcom_q6v5_mss.c
> > +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> > @@ -1989,8 +1989,14 @@ static int q6v5_probe(struct platform_device *pdev)
> >  	if (ret)
> >  		goto remove_sysmon_subdev;
> >  
> > +	ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > +	if (ret)
> > +		goto remove_rproc;
> > +
> >  	return 0;
> >  
> > +remove_rproc:
> > +	rproc_del(rproc);
> >  remove_sysmon_subdev:
> >  	qcom_remove_sysmon_subdev(qproc->sysmon);
> >  remove_subdevs:
> > @@ -2010,6 +2016,7 @@ static int q6v5_remove(struct platform_device *pdev)
> >  	struct q6v5 *qproc = platform_get_drvdata(pdev);
> >  	struct rproc *rproc = qproc->rproc;
> >  
> > +	of_platform_depopulate(&pdev->dev);
> >  	rproc_del(rproc);
> >  
> >  	qcom_q6v5_deinit(&qproc->q6v5);
> > -- 
> > 2.34.1
> >