Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1638659 > unrolled thread

[PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction

Started byPeter Ujfalusi <peter.ujfalusi@ti.com>
First post2017-05-10 10:50 +0200
Last post2017-05-10 18:40 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction Peter Ujfalusi <peter.ujfalusi@ti.com> - 2017-05-10 10:50 +0200
    Re: [PATCH v2 01/10] dmaengine: omap-dma: port_window support  correction for both direction Tony Lindgren <tony@atomide.com> - 2017-05-10 18:40 +0200

#1638659 — [PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2017-05-10 10:50 +0200
Subject[PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction
Message-ID<tFvtM-6TH-11@gated-at.bofh.it>
When the port_window support was verified it was done on setup where only
the MEM_TO_DEV direction was enabled. This got un-noticed and thus only
this direction worked.

Now that I have managed to get a setup to verify both direction it turned
out that the setup was incorrect:
omap_desc members are settings for the slave port while the omap_sg members
apply to the memory side of the sDMA setup.

Fixes: 527a27591312 ("dmaengine: omap-dma: Fix the port_window support")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: dmaengine@vger.kernel.org
Cc: dan.j.williams@intel.com
Cc: vinod.koul@intel.com
---
 drivers/dma/omap-dma.c | 39 +++++++++++++++------------------------
 1 file changed, 15 insertions(+), 24 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index eed745a598fa..4fc86d40b50c 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -948,12 +948,6 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 		return NULL;
 	}
 
-	/* When the port_window is used, one frame must cover the window */
-	if (port_window) {
-		burst = port_window;
-		port_window_bytes = port_window * es_bytes[es];
-	}
-
 	/* Now allocate and setup the descriptor. */
 	d = kzalloc(sizeof(*d) + sglen * sizeof(d->sg[0]), GFP_ATOMIC);
 	if (!d)
@@ -963,6 +957,21 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 	d->dev_addr = dev_addr;
 	d->es = es;
 
+	/* When the port_window is used, one frame must cover the window */
+	if (port_window) {
+		burst = port_window;
+		port_window_bytes = port_window * es_bytes[es];
+
+		d->ei = 1;
+		/*
+		 * One frame covers the port_window and by  configure
+		 * the source frame index to be -1 * (port_window - 1)
+		 * we instruct the sDMA that after a frame is processed
+		 * it should move back to the start of the window.
+		 */
+		d->fi = -(port_window_bytes - 1);
+	}
+
 	d->ccr = c->ccr | CCR_SYNC_FRAME;
 	if (dir == DMA_DEV_TO_MEM) {
 		d->csdp = CSDP_DST_BURST_64 | CSDP_DST_PACKED;
@@ -987,14 +996,6 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 		d->ccr |= CCR_SRC_AMODE_POSTINC;
 		if (port_window) {
 			d->ccr |= CCR_DST_AMODE_DBLIDX;
-			d->ei = 1;
-			/*
-			 * One frame covers the port_window and by  configure
-			 * the source frame index to be -1 * (port_window - 1)
-			 * we instruct the sDMA that after a frame is processed
-			 * it should move back to the start of the window.
-			 */
-			d->fi = -(port_window_bytes - 1);
 
 			if (port_window_bytes >= 64)
 				d->csdp |= CSDP_DST_BURST_64;
@@ -1050,16 +1051,6 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 		osg->addr = sg_dma_address(sgent);
 		osg->en = en;
 		osg->fn = sg_dma_len(sgent) / frame_bytes;
-		if (port_window && dir == DMA_DEV_TO_MEM) {
-			osg->ei = 1;
-			/*
-			 * One frame covers the port_window and by  configure
-			 * the source frame index to be -1 * (port_window - 1)
-			 * we instruct the sDMA that after a frame is processed
-			 * it should move back to the start of the window.
-			 */
-			osg->fi = -(port_window_bytes - 1);
-		}
 
 		if (d->using_ll) {
 			osg->t2_desc = dma_pool_alloc(od->desc_pool, GFP_ATOMIC,
-- 
2.12.2

[toc] | [next] | [standalone]


#1638958 — Re: [PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction

FromTony Lindgren <tony@atomide.com>
Date2017-05-10 18:40 +0200
SubjectRe: [PATCH v2 01/10] dmaengine: omap-dma: port_window support correction for both direction
Message-ID<tFCOC-31A-3@gated-at.bofh.it>
In reply to#1638659
* Peter Ujfalusi <peter.ujfalusi@ti.com> [170510 01:45]:
> When the port_window support was verified it was done on setup where only
> the MEM_TO_DEV direction was enabled. This got un-noticed and thus only
> this direction worked.
> 
> Now that I have managed to get a setup to verify both direction it turned
> out that the setup was incorrect:
> omap_desc members are settings for the slave port while the omap_sg members
> apply to the memory side of the sDMA setup.
> 
> Fixes: 527a27591312 ("dmaengine: omap-dma: Fix the port_window support")
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: dmaengine@vger.kernel.org
> Cc: dan.j.williams@intel.com
> Cc: vinod.koul@intel.com

Tested-by: Tony Lindgren <tony@atomide.com>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web