diff mbox

[V2,2/8] dmaengine: bcm2835: remove unnecessary masking of dma channels

Message ID 1452187987-2605-3-git-send-email-kernel@martin.sperl.org (mailing list archive)
State Changes Requested
Headers show

Commit Message

Martin Sperl Jan. 7, 2016, 5:33 p.m. UTC 
From: Martin Sperl <kernel@martin.sperl.org>

The original patch contained 3 dma channels that were masked out.

These - as far as research and discussions show - are a
artefacts remaining from the downstream legacy dma-api.

Right now down-stream still includes a legacy api used only
in a single (downstream only) driver (bcm2708_fb) that requires
2D DMA for speedup (DMA-channel 0).
Formerly the sd-card support driver also was using this legacy
api (DMA-channel 2), but since has been moved over to use
dmaengine directly.

The DMA-channel 3 is already masked out in the devicetree in
the default property "brcm,dma-channel-mask = <0x7f35>;"

So we can remove the whole masking of DMA channels.

Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
 drivers/dma/bcm2835-dma.c |    9 ---------
 1 file changed, 9 deletions(-)

Comments

Eric Anholt Jan. 30, 2016, 3:08 a.m. UTC | #1 
kernel@martin.sperl.org writes:

> From: Martin Sperl <kernel@martin.sperl.org>
>
> The original patch contained 3 dma channels that were masked out.
>
> These - as far as research and discussions show - are a
> artefacts remaining from the downstream legacy dma-api.
>
> Right now down-stream still includes a legacy api used only
> in a single (downstream only) driver (bcm2708_fb) that requires
> 2D DMA for speedup (DMA-channel 0).
> Formerly the sd-card support driver also was using this legacy
> api (DMA-channel 2), but since has been moved over to use
> dmaengine directly.
>
> The DMA-channel 3 is already masked out in the devicetree in
> the default property "brcm,dma-channel-mask = <0x7f35>;"

Delayed the rest of the review, because I went digging around in the
firmware, and missed the ifdef mess in it that produced 0x7f35.  As far
as I can tell, though, we should be using just that value to control
which channels we expose (other than the shared-irq issue).  If the
firmware wants to use a different set of channels some day, they'll have
to edit our DT.

Reviewed-by: Eric Anholt <eric@anholt.net>
diff mbox

Patch

diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 2d72fe8..e4ca980 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -123,9 +123,6 @@  struct bcm2835_desc {
 #define BCM2835_DMA_DATA_TYPE_S32	4
 #define BCM2835_DMA_DATA_TYPE_S128	16
 
-#define BCM2835_DMA_BULK_MASK	BIT(0)
-#define BCM2835_DMA_FIQ_MASK	(BIT(2) | BIT(3))
-
 /* Valid only for channels 0 - 14, 15 has its own base address */
 #define BCM2835_DMA_CHAN(n)	((n) << 8) /* Base address */
 #define BCM2835_DMA_CHANIO(base, n) ((base) + BCM2835_DMA_CHAN(n))
@@ -641,12 +638,6 @@  static int bcm2835_dma_probe(struct platform_device *pdev)
 		goto err_no_dma;
 	}
 
-	/*
-	 * Do not use the FIQ and BULK channels,
-	 * because they are used by the GPU.
-	 */
-	chans_available &= ~(BCM2835_DMA_FIQ_MASK | BCM2835_DMA_BULK_MASK);
-
 	for (i = 0; i < pdev->num_resources; i++) {
 		irq = platform_get_irq(pdev, i);
 		if (irq < 0)