[PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Stephan Gerhold]

The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
channels of modems integrated into many older Qualcomm SoCs, e.g.
Qualcomm MSM8916 or MSM8974.

Shortly said, BAM-DMUX is built using a simple protocol layer on top of
a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
a special mode where the modem/remote side is responsible for powering
on the BAM when needed but we are responsible to initialize it.
The BAM is powered off when unneeded by coordinating power control
via bidirectional interrupts from the BAM-DMUX driver.

This series adds one possible solution for handling the "powered remotely"
mode in the bam_dma driver.

For more information about BAM-DMUX itself, see the series on netdev:
https://lore.kernel.org/netdev/20211011141733.3999-5-stephan@gerhold.net/

Changes in v3:
  - Split dmaengine changes to a separate series
  - Address review comments from Bjorn

v2: https://lore.kernel.org/netdev/20211011141733.3999-1-stephan@gerhold.net/
RFC: https://lore.kernel.org/netdev/20210719145317.79692-1-stephan@gerhold.net/


Stephan Gerhold (2):
  dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode
  dmaengine: qcom: bam_dma: Add "powered remotely" mode

 .../devicetree/bindings/dma/qcom_bam_dma.txt  |  2 +
 drivers/dma/qcom/bam_dma.c                    | 90 ++++++++++++-------
 2 files changed, 59 insertions(+), 33 deletions(-)

-- 
2.33.0

[PATCH v3 1/2] dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode

[Stephan Gerhold]

In some configurations, the BAM DMA controller is set up by a remote
processor and the local processor can simply start making use of it
without setting up the BAM. This is already supported using the
"qcom,controlled-remotely" property.

However, for some reason another possible configuration is that the
remote processor is responsible for powering up the BAM, but we are
still responsible for initializing it (e.g. resetting it etc). Add
a "qcom,powered-remotely" property to describe that configuration.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
Changes in v3: None, split from BAM-DMUX patch set
Changes since RFC:
  - Rename qcom,remote-power-collapse -> qcom,powered-remotely
    for consistency with "qcom,controlled-remotely"

Also note that there is an ongoing effort to convert these bindings
to DT schema but sadly there were not any updates for a while. :/
https://lore.kernel.org/linux-arm-msm/20210519143700.27392-2-bhupesh.sharma@linaro.org/
---
 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
index cf5b9e44432c..6e9a5497b3f2 100644
--- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -15,6 +15,8 @@ Required properties:
   the secure world.
 - qcom,controlled-remotely : optional, indicates that the bam is controlled by
   remote proccessor i.e. execution environment.
+- qcom,powered-remotely : optional, indicates that the bam is powered up by
+  a remote processor but must be initialized by the local processor.
 - num-channels : optional, indicates supported number of DMA channels in a
   remotely controlled bam.
 - qcom,num-ees : optional, indicates supported number of Execution Environments
-- 
2.33.0

Re: [PATCH v3 1/2] dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode

[Rob Herring]

On Mon, 18 Oct 2021 12:24:20 +0200, Stephan Gerhold wrote:
> In some configurations, the BAM DMA controller is set up by a remote
> processor and the local processor can simply start making use of it
> without setting up the BAM. This is already supported using the
> "qcom,controlled-remotely" property.
> 
> However, for some reason another possible configuration is that the
> remote processor is responsible for powering up the BAM, but we are
> still responsible for initializing it (e.g. resetting it etc). Add
> a "qcom,powered-remotely" property to describe that configuration.
> 
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> ---
> Changes in v3: None, split from BAM-DMUX patch set
> Changes since RFC:
>   - Rename qcom,remote-power-collapse -> qcom,powered-remotely
>     for consistency with "qcom,controlled-remotely"
> 
> Also note that there is an ongoing effort to convert these bindings
> to DT schema but sadly there were not any updates for a while. :/
> https://lore.kernel.org/linux-arm-msm/20210519143700.27392-2-bhupesh.sharma@linaro.org/
> ---
>  Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v3 2/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode

[Stephan Gerhold]

In some configurations, the BAM DMA controller is set up by a remote
processor and the local processor can simply start making use of it
without setting up the BAM. This is already supported using the
"qcom,controlled-remotely" property.

However, for some reason another possible configuration is that the
remote processor is responsible for powering up the BAM, but we are
still responsible for initializing it (e.g. resetting it etc).

This configuration is quite challenging to handle properly because
the power control is handled through separate channels
(e.g. device-specific SMSM interrupts / smem-states). Great care
must be taken to ensure the BAM registers are not accessed while
the BAM is powered off since this results in a bus stall.

Attempt to support this configuration with minimal device-specific
code in the bam_dma driver by tracking the number of requested
channels. Consumers of DMA channels are responsible to only request
DMA channels when the BAM was powered on by the remote processor,
and to release them before the BAM is powered off.

When the first channel is requested the BAM is initialized (reset)
and it is also put into reset when the last channel was released.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
Changes in v3: Address review comment from Bjorn
  - Add missing () in documentation comment
  - Flip if condition to clarify code a bit
Changes since RFC:
  - Drop qcom-specific terminology "power collapse", instead rename
    "qcom,remote-power-collapse" -> "qcom,powered-remotely"

See original RFC for a discussion of alternative approaches to handle
this configuration:
  https://lore.kernel.org/netdev/20210719145317.79692-3-stephan@gerhold.net/
---
 drivers/dma/qcom/bam_dma.c | 90 ++++++++++++++++++++++++--------------
 1 file changed, 57 insertions(+), 33 deletions(-)

diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index c8a77b428b52..87f6ca1541cf 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -388,6 +388,8 @@ struct bam_device {
 	/* execution environment ID, from DT */
 	u32 ee;
 	bool controlled_remotely;
+	bool powered_remotely;
+	u32 active_channels;
 
 	const struct reg_offset_data *layout;
 
@@ -415,6 +417,44 @@ static inline void __iomem *bam_addr(struct bam_device *bdev, u32 pipe,
 		r.ee_mult * bdev->ee;
 }
 
+/**
+ * bam_reset() - reset and initialize BAM registers
+ * @bdev: bam device
+ */
+static void bam_reset(struct bam_device *bdev)
+{
+	u32 val;
+
+	/* s/w reset bam */
+	/* after reset all pipes are disabled and idle */
+	val = readl_relaxed(bam_addr(bdev, 0, BAM_CTRL));
+	val |= BAM_SW_RST;
+	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
+	val &= ~BAM_SW_RST;
+	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
+
+	/* make sure previous stores are visible before enabling BAM */
+	wmb();
+
+	/* enable bam */
+	val |= BAM_EN;
+	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
+
+	/* set descriptor threshhold, start with 4 bytes */
+	writel_relaxed(DEFAULT_CNT_THRSHLD,
+			bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
+
+	/* Enable default set of h/w workarounds, ie all except BAM_FULL_PIPE */
+	writel_relaxed(BAM_CNFG_BITS_DEFAULT, bam_addr(bdev, 0, BAM_CNFG_BITS));
+
+	/* enable irqs for errors */
+	writel_relaxed(BAM_ERROR_EN | BAM_HRESP_ERR_EN,
+			bam_addr(bdev, 0, BAM_IRQ_EN));
+
+	/* unmask global bam interrupt */
+	writel_relaxed(BAM_IRQ_MSK, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
+}
+
 /**
  * bam_reset_channel - Reset individual BAM DMA channel
  * @bchan: bam channel
@@ -512,6 +552,9 @@ static int bam_alloc_chan(struct dma_chan *chan)
 		return -ENOMEM;
 	}
 
+	if (bdev->active_channels++ == 0 && bdev->powered_remotely)
+		bam_reset(bdev);
+
 	return 0;
 }
 
@@ -565,6 +608,13 @@ static void bam_free_chan(struct dma_chan *chan)
 	/* disable irq */
 	writel_relaxed(0, bam_addr(bdev, bchan->id, BAM_P_IRQ_EN));
 
+	if (--bdev->active_channels == 0 && bdev->powered_remotely) {
+		/* s/w reset bam */
+		val = readl_relaxed(bam_addr(bdev, 0, BAM_CTRL));
+		val |= BAM_SW_RST;
+		writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
+	}
+
 err:
 	pm_runtime_mark_last_busy(bdev->dev);
 	pm_runtime_put_autosuspend(bdev->dev);
@@ -1164,37 +1214,9 @@ static int bam_init(struct bam_device *bdev)
 		bdev->num_channels = val & BAM_NUM_PIPES_MASK;
 	}
 
-	if (bdev->controlled_remotely)
-		return 0;
-
-	/* s/w reset bam */
-	/* after reset all pipes are disabled and idle */
-	val = readl_relaxed(bam_addr(bdev, 0, BAM_CTRL));
-	val |= BAM_SW_RST;
-	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
-	val &= ~BAM_SW_RST;
-	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
-
-	/* make sure previous stores are visible before enabling BAM */
-	wmb();
-
-	/* enable bam */
-	val |= BAM_EN;
-	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
-
-	/* set descriptor threshhold, start with 4 bytes */
-	writel_relaxed(DEFAULT_CNT_THRSHLD,
-			bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
-
-	/* Enable default set of h/w workarounds, ie all except BAM_FULL_PIPE */
-	writel_relaxed(BAM_CNFG_BITS_DEFAULT, bam_addr(bdev, 0, BAM_CNFG_BITS));
-
-	/* enable irqs for errors */
-	writel_relaxed(BAM_ERROR_EN | BAM_HRESP_ERR_EN,
-			bam_addr(bdev, 0, BAM_IRQ_EN));
-
-	/* unmask global bam interrupt */
-	writel_relaxed(BAM_IRQ_MSK, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
+	/* Reset BAM now if fully controlled locally */
+	if (!bdev->controlled_remotely && !bdev->powered_remotely)
+		bam_reset(bdev);
 
 	return 0;
 }
@@ -1257,8 +1279,10 @@ static int bam_dma_probe(struct platform_device *pdev)
 
 	bdev->controlled_remotely = of_property_read_bool(pdev->dev.of_node,
 						"qcom,controlled-remotely");
+	bdev->powered_remotely = of_property_read_bool(pdev->dev.of_node,
+						"qcom,powered-remotely");
 
-	if (bdev->controlled_remotely) {
+	if (bdev->controlled_remotely || bdev->powered_remotely) {
 		ret = of_property_read_u32(pdev->dev.of_node, "num-channels",
 					   &bdev->num_channels);
 		if (ret)
@@ -1270,7 +1294,7 @@ static int bam_dma_probe(struct platform_device *pdev)
 			dev_err(bdev->dev, "num-ees unspecified in dt\n");
 	}
 
-	if (bdev->controlled_remotely)
+	if (bdev->controlled_remotely || bdev->powered_remotely)
 		bdev->bamclk = devm_clk_get_optional(bdev->dev, "bam_clk");
 	else
 		bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
-- 
2.33.0

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Vinod Koul]

On 18-10-21, 12:24, Stephan Gerhold wrote:
> The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> channels of modems integrated into many older Qualcomm SoCs, e.g.
> Qualcomm MSM8916 or MSM8974.
> 
> Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> a special mode where the modem/remote side is responsible for powering
> on the BAM when needed but we are responsible to initialize it.
> The BAM is powered off when unneeded by coordinating power control
> via bidirectional interrupts from the BAM-DMUX driver.
> 
> This series adds one possible solution for handling the "powered remotely"
> mode in the bam_dma driver.

This looks good me me. Bhupesh/Stephan what was the conclusion on the
the discussion you folks had?

> 
> For more information about BAM-DMUX itself, see the series on netdev:
> https://lore.kernel.org/netdev/20211011141733.3999-5-stephan@gerhold.net/
> 
> Changes in v3:
>   - Split dmaengine changes to a separate series
>   - Address review comments from Bjorn
> 
> v2: https://lore.kernel.org/netdev/20211011141733.3999-1-stephan@gerhold.net/
> RFC: https://lore.kernel.org/netdev/20210719145317.79692-1-stephan@gerhold.net/
> 
> 
> Stephan Gerhold (2):
>   dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode
>   dmaengine: qcom: bam_dma: Add "powered remotely" mode
> 
>  .../devicetree/bindings/dma/qcom_bam_dma.txt  |  2 +
>  drivers/dma/qcom/bam_dma.c                    | 90 ++++++++++++-------
>  2 files changed, 59 insertions(+), 33 deletions(-)
> 
> -- 
> 2.33.0

-- 
~Vinod

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Stephan Gerhold]

On Mon, Oct 25, 2021 at 11:18:08AM +0530, Vinod Koul wrote:
> On 18-10-21, 12:24, Stephan Gerhold wrote:
> > The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> > channels of modems integrated into many older Qualcomm SoCs, e.g.
> > Qualcomm MSM8916 or MSM8974.
> > 
> > Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> > a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> > a special mode where the modem/remote side is responsible for powering
> > on the BAM when needed but we are responsible to initialize it.
> > The BAM is powered off when unneeded by coordinating power control
> > via bidirectional interrupts from the BAM-DMUX driver.
> > 
> > This series adds one possible solution for handling the "powered remotely"
> > mode in the bam_dma driver.
> 
> This looks good me me. Bhupesh/Stephan what was the conclusion on the
> the discussion you folks had?
> 

Basically I said I would wait if you still want to take this for 5.16. :)
There is a conflict with the DT schema conversion in Bhupesh's series,
but it's trivial to solve no matter which of the patches is applied first.

Since Bhupesh still needs to send v5 as far as I can tell (and has a
much larger series overall), I think it's fine to apply this one first.

Bhupesh, you can just copy-paste this below qcom,controlled-remotely
in your DT schema if Vinod applies this patch first:

  qcom,powered-remotely:
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      Indicates that the bam is powered up by a remote processor
      but must be initialized by the local processor.

Thanks!
Stephan

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Bhupesh Sharma]

Hi Stephan and Vinod,

On Mon, 25 Oct 2021 at 11:47, Stephan Gerhold <stephan@gerhold.net> wrote:
>
> On Mon, Oct 25, 2021 at 11:18:08AM +0530, Vinod Koul wrote:
> > On 18-10-21, 12:24, Stephan Gerhold wrote:
> > > The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> > > channels of modems integrated into many older Qualcomm SoCs, e.g.
> > > Qualcomm MSM8916 or MSM8974.
> > >
> > > Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> > > a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> > > a special mode where the modem/remote side is responsible for powering
> > > on the BAM when needed but we are responsible to initialize it.
> > > The BAM is powered off when unneeded by coordinating power control
> > > via bidirectional interrupts from the BAM-DMUX driver.
> > >
> > > This series adds one possible solution for handling the "powered remotely"
> > > mode in the bam_dma driver.
> >
> > This looks good me me. Bhupesh/Stephan what was the conclusion on the
> > the discussion you folks had?
> >
>
> Basically I said I would wait if you still want to take this for 5.16. :)
> There is a conflict with the DT schema conversion in Bhupesh's series,
> but it's trivial to solve no matter which of the patches is applied first.
>
> Since Bhupesh still needs to send v5 as far as I can tell (and has a
> much larger series overall), I think it's fine to apply this one first.
>
> Bhupesh, you can just copy-paste this below qcom,controlled-remotely
> in your DT schema if Vinod applies this patch first:
>
>   qcom,powered-remotely:
>     $ref: /schemas/types.yaml#/definitions/flag
>     description:
>       Indicates that the bam is powered up by a remote processor
>       but must be initialized by the local processor.

Sure, I can respin my v5 with 'qcom,powered-remotely' property added,
if this series gets applied first. Can I add you S-o-B to the same?

Thanks,
Bhupesh

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Stephan Gerhold]

Hi Bhupesh,

On Thu, Oct 28, 2021 at 12:20:35PM +0530, Bhupesh Sharma wrote:
> On Mon, 25 Oct 2021 at 11:47, Stephan Gerhold <stephan@gerhold.net> wrote:
> >
> > On Mon, Oct 25, 2021 at 11:18:08AM +0530, Vinod Koul wrote:
> > > On 18-10-21, 12:24, Stephan Gerhold wrote:
> > > > The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> > > > channels of modems integrated into many older Qualcomm SoCs, e.g.
> > > > Qualcomm MSM8916 or MSM8974.
> > > >
> > > > Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> > > > a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> > > > a special mode where the modem/remote side is responsible for powering
> > > > on the BAM when needed but we are responsible to initialize it.
> > > > The BAM is powered off when unneeded by coordinating power control
> > > > via bidirectional interrupts from the BAM-DMUX driver.
> > > >
> > > > This series adds one possible solution for handling the "powered remotely"
> > > > mode in the bam_dma driver.
> > >
> > > This looks good me me. Bhupesh/Stephan what was the conclusion on the
> > > the discussion you folks had?
> > >
> >
> > Basically I said I would wait if you still want to take this for 5.16. :)
> > There is a conflict with the DT schema conversion in Bhupesh's series,
> > but it's trivial to solve no matter which of the patches is applied first.
> >
> > Since Bhupesh still needs to send v5 as far as I can tell (and has a
> > much larger series overall), I think it's fine to apply this one first.
> >
> > Bhupesh, you can just copy-paste this below qcom,controlled-remotely
> > in your DT schema if Vinod applies this patch first:
> >
> >   qcom,powered-remotely:
> >     $ref: /schemas/types.yaml#/definitions/flag
> >     description:
> >       Indicates that the bam is powered up by a remote processor
> >       but must be initialized by the local processor.
> 
> Sure, I can respin my v5 with 'qcom,powered-remotely' property added,
> if this series gets applied first.

Thanks!

> Can I add you S-o-B to the same?

I literally just copy-pasted this from "qcom,controlled-remotely" in
your patch with the description from my dt-bindings change that already
has my S-o-B. I don't think it is necessary to add my S-o-B to your
patch as well just for this. :)

Thanks,
Stephan

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Bhupesh Sharma]

On Thu, 28 Oct 2021 at 12:45, Stephan Gerhold <stephan@gerhold.net> wrote:
>
> Hi Bhupesh,
>
> On Thu, Oct 28, 2021 at 12:20:35PM +0530, Bhupesh Sharma wrote:
> > On Mon, 25 Oct 2021 at 11:47, Stephan Gerhold <stephan@gerhold.net> wrote:
> > >
> > > On Mon, Oct 25, 2021 at 11:18:08AM +0530, Vinod Koul wrote:
> > > > On 18-10-21, 12:24, Stephan Gerhold wrote:
> > > > > The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> > > > > channels of modems integrated into many older Qualcomm SoCs, e.g.
> > > > > Qualcomm MSM8916 or MSM8974.
> > > > >
> > > > > Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> > > > > a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> > > > > a special mode where the modem/remote side is responsible for powering
> > > > > on the BAM when needed but we are responsible to initialize it.
> > > > > The BAM is powered off when unneeded by coordinating power control
> > > > > via bidirectional interrupts from the BAM-DMUX driver.
> > > > >
> > > > > This series adds one possible solution for handling the "powered remotely"
> > > > > mode in the bam_dma driver.
> > > >
> > > > This looks good me me. Bhupesh/Stephan what was the conclusion on the
> > > > the discussion you folks had?
> > > >
> > >
> > > Basically I said I would wait if you still want to take this for 5.16. :)
> > > There is a conflict with the DT schema conversion in Bhupesh's series,
> > > but it's trivial to solve no matter which of the patches is applied first.
> > >
> > > Since Bhupesh still needs to send v5 as far as I can tell (and has a
> > > much larger series overall), I think it's fine to apply this one first.
> > >
> > > Bhupesh, you can just copy-paste this below qcom,controlled-remotely
> > > in your DT schema if Vinod applies this patch first:
> > >
> > >   qcom,powered-remotely:
> > >     $ref: /schemas/types.yaml#/definitions/flag
> > >     description:
> > >       Indicates that the bam is powered up by a remote processor
> > >       but must be initialized by the local processor.
> >
> > Sure, I can respin my v5 with 'qcom,powered-remotely' property added,
> > if this series gets applied first.
>
> Thanks!
>
> > Can I add you S-o-B to the same?
>
> I literally just copy-pasted this from "qcom,controlled-remotely" in
> your patch with the description from my dt-bindings change that already
> has my S-o-B. I don't think it is necessary to add my S-o-B to your
> patch as well just for this. :)

Great, thanks. I will handle the "qcom,controlled-remotely" in my v5 patchset.

Otherwise, the series looks good to me, so:
Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Regards.

Re: [PATCH v3 0/2] dmaengine: qcom: bam_dma: Add "powered remotely" mode for BAM-DMUX

[Vinod Koul]

On 18-10-21, 12:24, Stephan Gerhold wrote:
> The BAM Data Multiplexer (BAM-DMUX) provides access to the network data
> channels of modems integrated into many older Qualcomm SoCs, e.g.
> Qualcomm MSM8916 or MSM8974.
> 
> Shortly said, BAM-DMUX is built using a simple protocol layer on top of
> a DMA engine (Qualcomm BAM DMA). For BAM-DMUX, the BAM DMA engine runs in
> a special mode where the modem/remote side is responsible for powering
> on the BAM when needed but we are responsible to initialize it.
> The BAM is powered off when unneeded by coordinating power control
> via bidirectional interrupts from the BAM-DMUX driver.
> 
> This series adds one possible solution for handling the "powered remotely"
> mode in the bam_dma driver.

Applied, thanks

-- 
~Vinod