[PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

The following patch series moves code to setup the DMA hardware and
service interrupts from the hardware to the DMA engine driver.  This
reduces the dependency on the legacy DMA implementation.

This series does not remove the channel allocation/freeing hooks which
are used to manage the allocation of physical channels - this is the
next step in the evolution.

The patches which move the interrupt handling are currently less than
perfect since they're writing to ENABLE_L0 under a different spinlock,
and hence RFC only at the moment.

 arch/arm/mach-omap1/dma.c |  183 +++++--------
 arch/arm/mach-omap2/dma.c |  183 ++++++--------
 arch/arm/plat-omap/dma.c  |   17 +-
 drivers/dma/omap-dma.c    |  653 ++++++++++++++++++++++++++++++++++++++++-----
 include/linux/omap-dma.h  |   25 ++-
 5 files changed, 774 insertions(+), 287 deletions(-)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH RFC 01/26] dmaengine: omap-dma: use devm_kzalloc() to allocate omap_dmadev.

[Russell King]

Use devm_kzalloc() to allocate omap_dmadev() so that we don't need
complex error cleanup paths.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/dma/omap-dma.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2f66cf4e54fe..d9349be33bdf 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -594,7 +594,6 @@ static void omap_dma_free(struct omap_dmadev *od)
 		tasklet_kill(&c->vc.task);
 		kfree(c);
 	}
-	kfree(od);
 }
 
 static int omap_dma_probe(struct platform_device *pdev)
@@ -602,7 +601,7 @@ static int omap_dma_probe(struct platform_device *pdev)
 	struct omap_dmadev *od;
 	int rc, i;
 
-	od = kzalloc(sizeof(*od), GFP_KERNEL);
+	od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
 	if (!od)
 		return -ENOMEM;
 
-- 
1.7.4.4

[PATCH RFC 02/26] dmaengine: omap-dma: provide a hook to get the underlying DMA platform ops

[Russell King]

Provide and use a hook to obtain the underlying DMA platform operations
so that omap-dma.c can access the hardware more directly without
involving the legacy DMA driver.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/plat-omap/dma.c |    6 ++++++
 drivers/dma/omap-dma.c   |    7 +++++++
 include/linux/omap-dma.h |    2 ++
 3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 01619c2910e3..d4d9a5e62152 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2000,6 +2000,12 @@ void omap_dma_global_context_restore(void)
 			omap_clear_dma(ch);
 }
 
+struct omap_system_dma_plat_info *omap_get_plat_info(void)
+{
+	return p;
+}
+EXPORT_SYMBOL_GPL(omap_get_plat_info);
+
 static int omap_system_dma_probe(struct platform_device *pdev)
 {
 	int ch, ret = 0;
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index d9349be33bdf..3c1bb34aad0a 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -26,11 +26,13 @@ struct omap_dmadev {
 	spinlock_t lock;
 	struct tasklet_struct task;
 	struct list_head pending;
+	struct omap_system_dma_plat_info *plat;
 };
 
 struct omap_chan {
 	struct virt_dma_chan vc;
 	struct list_head node;
+	struct omap_system_dma_plat_info *plat;
 
 	struct dma_slave_config	cfg;
 	unsigned dma_sig;
@@ -573,6 +575,7 @@ static int omap_dma_chan_init(struct omap_dmadev *od, int dma_sig)
 	if (!c)
 		return -ENOMEM;
 
+	c->plat = od->plat;
 	c->dma_sig = dma_sig;
 	c->vc.desc_free = omap_dma_desc_free;
 	vchan_init(&c->vc, &od->ddev);
@@ -605,6 +608,10 @@ static int omap_dma_probe(struct platform_device *pdev)
 	if (!od)
 		return -ENOMEM;
 
+	od->plat = omap_get_plat_info();
+	if (!od->plat)
+		return -EPROBE_DEFER;
+
 	dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
 	dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask);
 	od->ddev.device_alloc_chan_resources = omap_dma_alloc_chan_resources;
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9c9c51..14742fc2aefe 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -292,6 +292,8 @@ struct omap_system_dma_plat_info {
 #define dma_omap15xx()	((dma_omap1() && (d->dev_caps & ENABLE_1510_MODE)))
 #define dma_omap16xx()	((dma_omap1() && (d->dev_caps & ENABLE_16XX_MODE)))
 
+extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
+
 extern void omap_set_dma_priority(int lch, int dst_port, int priority);
 extern int omap_request_dma(int dev_id, const char *dev_name,
 			void (*callback)(int lch, u16 ch_status, void *data),
-- 
1.7.4.4

[PATCH RFC 03/26] dmaengine: omap-dma: program hardware directly

[Russell King]

Program the transfer parameters directly into the hardware, rather
than using the functions in arch/arm/plat-omap/dma.c.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/dma/omap-dma.c   |  144 ++++++++++++++++++++++++++++++++++++++++-----
 include/linux/omap-dma.h |    6 +-
 2 files changed, 132 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 3c1bb34aad0a..dd233ca2cf5a 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -99,16 +99,96 @@ static void omap_dma_start_sg(struct omap_chan *c, struct omap_desc *d,
 	unsigned idx)
 {
 	struct omap_sg *sg = d->sg + idx;
+	uint32_t val;
+
+	if (d->dir == DMA_DEV_TO_MEM) {
+		if (dma_omap1()) {
+			val = c->plat->dma_read(CSDP, c->dma_ch);
+			val &= ~(0x1f << 9);
+			val |= OMAP_DMA_PORT_EMIFF << 9;
+			c->plat->dma_write(val, CSDP, c->dma_ch);
+		}
 
-	if (d->dir == DMA_DEV_TO_MEM)
-		omap_set_dma_dest_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
-			OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
-	else
-		omap_set_dma_src_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
-			OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
+		val = c->plat->dma_read(CCR, c->dma_ch);
+		val &= ~(0x03 << 14);
+		val |= OMAP_DMA_AMODE_POST_INC << 14;
+		c->plat->dma_write(val, CCR, c->dma_ch);
+
+		c->plat->dma_write(sg->addr, CDSA, c->dma_ch);
+		c->plat->dma_write(0, CDEI, c->dma_ch);
+		c->plat->dma_write(0, CDFI, c->dma_ch);
+	} else {
+		if (dma_omap1()) {
+			val = c->plat->dma_read(CSDP, c->dma_ch);
+			val &= ~(0x1f << 2);
+			val |= OMAP_DMA_PORT_EMIFF << 2;
+			c->plat->dma_write(val, CSDP, c->dma_ch);
+		}
+
+		val = c->plat->dma_read(CCR, c->dma_ch);
+		val &= ~(0x03 << 12);
+		val |= OMAP_DMA_AMODE_POST_INC << 12;
+		c->plat->dma_write(val, CCR, c->dma_ch);
+
+		c->plat->dma_write(sg->addr, CSSA, c->dma_ch);
+		c->plat->dma_write(0, CSEI, c->dma_ch);
+		c->plat->dma_write(0, CSFI, c->dma_ch);
+	}
+
+	val = c->plat->dma_read(CSDP, c->dma_ch);
+	val &= ~0x03;
+	val |= d->es;
+	c->plat->dma_write(val, CSDP, c->dma_ch);
+
+	if (dma_omap1()) {
+		val = c->plat->dma_read(CCR, c->dma_ch);
+		val &= ~(1 << 5);
+		if (d->sync_mode == OMAP_DMA_SYNC_FRAME)
+			val |= 1 << 5;
+		c->plat->dma_write(val, CCR, c->dma_ch);
+
+		val = c->plat->dma_read(CCR2, c->dma_ch);
+		val &= ~(1 << 2);
+		if (d->sync_mode == OMAP_DMA_SYNC_BLOCK)
+			val |= 1 << 2;
+		c->plat->dma_write(val, CCR2, c->dma_ch);
+	}
+
+	if (dma_omap2plus() && c->dma_sig) {
+		val = c->plat->dma_read(CCR, c->dma_ch);
+
+		/* DMA_SYNCHRO_CONTROL_UPPER depends on the channel number */
+		val &= ~((1 << 23) | (3 << 19) | 0x1f);
+		val |= (c->dma_sig & ~0x1f) << 14;
+		val |= c->dma_sig & 0x1f;
+
+		if (d->sync_mode & OMAP_DMA_SYNC_FRAME)
+			val |= 1 << 5;
+		else
+			val &= ~(1 << 5);
 
-	omap_set_dma_transfer_params(c->dma_ch, d->es, sg->en, sg->fn,
-		d->sync_mode, c->dma_sig, d->sync_type);
+		if (d->sync_mode & OMAP_DMA_SYNC_BLOCK)
+			val |= 1 << 18;
+		else
+			val &= ~(1 << 18);
+
+		switch (d->sync_type) {
+		case OMAP_DMA_DST_SYNC_PREFETCH:
+			val &= ~(1 << 24);	/* dest synch */
+			val |= 1 << 23;		/* Prefetch */
+			break;
+		case 0:
+			val &= ~(1 << 24);	/* dest synch */
+			break;
+		default:
+			val |= 1 << 24;		/* source synch */
+			break;
+		}
+		c->plat->dma_write(val, CCR, c->dma_ch);
+	}
+
+	c->plat->dma_write(sg->en, CEN, c->dma_ch);
+	c->plat->dma_write(sg->fn, CFN, c->dma_ch);
 
 	omap_start_dma(c->dma_ch);
 }
@@ -117,6 +197,7 @@ static void omap_dma_start_desc(struct omap_chan *c)
 {
 	struct virt_dma_desc *vd = vchan_next_desc(&c->vc);
 	struct omap_desc *d;
+	uint32_t val;
 
 	if (!vd) {
 		c->desc = NULL;
@@ -128,12 +209,39 @@ static void omap_dma_start_desc(struct omap_chan *c)
 	c->desc = d = to_omap_dma_desc(&vd->tx);
 	c->sgidx = 0;
 
-	if (d->dir == DMA_DEV_TO_MEM)
-		omap_set_dma_src_params(c->dma_ch, d->periph_port,
-			OMAP_DMA_AMODE_CONSTANT, d->dev_addr, 0, d->fi);
-	else
-		omap_set_dma_dest_params(c->dma_ch, d->periph_port,
-			OMAP_DMA_AMODE_CONSTANT, d->dev_addr, 0, d->fi);
+	if (d->dir == DMA_DEV_TO_MEM) {
+		if (dma_omap1()) {
+			val = c->plat->dma_read(CSDP, c->dma_ch);
+			val &= ~(0x1f << 2);
+			val |= d->periph_port << 2;
+			c->plat->dma_write(val, CSDP, c->dma_ch);
+		}
+
+		val = c->plat->dma_read(CCR, c->dma_ch);
+		val &= ~(0x03 << 12);
+		val |= OMAP_DMA_AMODE_CONSTANT << 12;
+		c->plat->dma_write(val, CCR, c->dma_ch);
+
+		c->plat->dma_write(d->dev_addr, CSSA, c->dma_ch);
+		c->plat->dma_write(0, CSEI, c->dma_ch);
+		c->plat->dma_write(d->fi, CSFI, c->dma_ch);
+	} else {
+		if (dma_omap1()) {
+			val = c->plat->dma_read(CSDP, c->dma_ch);
+			val &= ~(0x1f << 9);
+			val |= d->periph_port << 9;
+			c->plat->dma_write(val, CSDP, c->dma_ch);
+		}
+
+		val = c->plat->dma_read(CCR, c->dma_ch);
+		val &= ~(0x03 << 14);
+		val |= OMAP_DMA_AMODE_CONSTANT << 14;
+		c->plat->dma_write(val, CCR, c->dma_ch);
+
+		c->plat->dma_write(d->dev_addr, CDSA, c->dma_ch);
+		c->plat->dma_write(0, CDEI, c->dma_ch);
+		c->plat->dma_write(d->fi, CDFI, c->dma_ch);
+	}
 
 	omap_dma_start_sg(c, d, 0);
 }
@@ -452,8 +560,12 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
 	}
 
 	if (dma_omap2plus()) {
-		omap_set_dma_src_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16);
-		omap_set_dma_dest_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16);
+		uint32_t val;
+
+		val = c->plat->dma_read(CSDP, c->dma_ch);
+		val |= 0x03 << 7; /* src burst mode 16 */
+		val |= 0x03 << 14; /* dst burst mode 16 */
+		c->plat->dma_write(val, CSDP, c->dma_ch);
 	}
 
 	return vchan_tx_prep(&c->vc, &d->vd, flags);
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 14742fc2aefe..d631658e2237 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -289,8 +289,10 @@ struct omap_system_dma_plat_info {
 #define dma_omap2plus()	0
 #endif
 #define dma_omap1()	(!dma_omap2plus())
-#define dma_omap15xx()	((dma_omap1() && (d->dev_caps & ENABLE_1510_MODE)))
-#define dma_omap16xx()	((dma_omap1() && (d->dev_caps & ENABLE_16XX_MODE)))
+#define __dma_omap15xx(d) (dma_omap1() && (d)->dev_caps & ENABLE_1510_MODE)
+#define __dma_omap16xx(d) (dma_omap1() && (d)->dev_caps & ENABLE_16XX_MODE)
+#define dma_omap15xx()	__dma_omap15xx(d)
+#define dma_omap16xx()	__dma_omap16xx(d)
 
 extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
 
-- 
1.7.4.4

[PATCH RFC 04/26] dmaengine: omap-dma: consolidate writes to DMA registers

[Russell King]

There's no need to keep writing registers which don't change value in
omap_dma_start_sg().  Move this into omap_dma_start_desc() and merge
the register updates together.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/dma/omap-dma.c |  123 +++++++++++++++++++-----------------------------
 1 files changed, 48 insertions(+), 75 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index dd233ca2cf5a..602c98aebca8 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -99,40 +99,75 @@ static void omap_dma_start_sg(struct omap_chan *c, struct omap_desc *d,
 	unsigned idx)
 {
 	struct omap_sg *sg = d->sg + idx;
+
+	if (d->dir == DMA_DEV_TO_MEM) {
+		c->plat->dma_write(sg->addr, CDSA, c->dma_ch);
+		c->plat->dma_write(0, CDEI, c->dma_ch);
+		c->plat->dma_write(0, CDFI, c->dma_ch);
+	} else {
+		c->plat->dma_write(sg->addr, CSSA, c->dma_ch);
+		c->plat->dma_write(0, CSEI, c->dma_ch);
+		c->plat->dma_write(0, CSFI, c->dma_ch);
+	}
+
+	c->plat->dma_write(sg->en, CEN, c->dma_ch);
+	c->plat->dma_write(sg->fn, CFN, c->dma_ch);
+
+	omap_start_dma(c->dma_ch);
+}
+
+static void omap_dma_start_desc(struct omap_chan *c)
+{
+	struct virt_dma_desc *vd = vchan_next_desc(&c->vc);
+	struct omap_desc *d;
 	uint32_t val;
 
+	if (!vd) {
+		c->desc = NULL;
+		return;
+	}
+
+	list_del(&vd->node);
+
+	c->desc = d = to_omap_dma_desc(&vd->tx);
+	c->sgidx = 0;
+
 	if (d->dir == DMA_DEV_TO_MEM) {
 		if (dma_omap1()) {
 			val = c->plat->dma_read(CSDP, c->dma_ch);
-			val &= ~(0x1f << 9);
+			val &= ~(0x1f << 9 | 0x1f << 2);
 			val |= OMAP_DMA_PORT_EMIFF << 9;
+			val |= d->periph_port << 2;
 			c->plat->dma_write(val, CSDP, c->dma_ch);
 		}
 
 		val = c->plat->dma_read(CCR, c->dma_ch);
-		val &= ~(0x03 << 14);
+		val &= ~(0x03 << 14 | 0x03 << 12);
 		val |= OMAP_DMA_AMODE_POST_INC << 14;
+		val |= OMAP_DMA_AMODE_CONSTANT << 12;
 		c->plat->dma_write(val, CCR, c->dma_ch);
 
-		c->plat->dma_write(sg->addr, CDSA, c->dma_ch);
-		c->plat->dma_write(0, CDEI, c->dma_ch);
-		c->plat->dma_write(0, CDFI, c->dma_ch);
+		c->plat->dma_write(d->dev_addr, CSSA, c->dma_ch);
+		c->plat->dma_write(0, CSEI, c->dma_ch);
+		c->plat->dma_write(d->fi, CSFI, c->dma_ch);
 	} else {
 		if (dma_omap1()) {
 			val = c->plat->dma_read(CSDP, c->dma_ch);
-			val &= ~(0x1f << 2);
+			val &= ~(0x1f << 9 | 0x1f << 2);
+			val |= d->periph_port << 9;
 			val |= OMAP_DMA_PORT_EMIFF << 2;
 			c->plat->dma_write(val, CSDP, c->dma_ch);
 		}
 
 		val = c->plat->dma_read(CCR, c->dma_ch);
-		val &= ~(0x03 << 12);
+		val &= ~(0x03 << 12 | 0x03 << 14);
+		val |= OMAP_DMA_AMODE_CONSTANT << 14;
 		val |= OMAP_DMA_AMODE_POST_INC << 12;
 		c->plat->dma_write(val, CCR, c->dma_ch);
 
-		c->plat->dma_write(sg->addr, CSSA, c->dma_ch);
-		c->plat->dma_write(0, CSEI, c->dma_ch);
-		c->plat->dma_write(0, CSFI, c->dma_ch);
+		c->plat->dma_write(d->dev_addr, CDSA, c->dma_ch);
+		c->plat->dma_write(0, CDEI, c->dma_ch);
+		c->plat->dma_write(d->fi, CDFI, c->dma_ch);
 	}
 
 	val = c->plat->dma_read(CSDP, c->dma_ch);
@@ -158,91 +193,29 @@ static void omap_dma_start_sg(struct omap_chan *c, struct omap_desc *d,
 		val = c->plat->dma_read(CCR, c->dma_ch);
 
 		/* DMA_SYNCHRO_CONTROL_UPPER depends on the channel number */
-		val &= ~((1 << 23) | (3 << 19) | 0x1f);
+		val &= ~(1 << 24 | 1 << 23 | 3 << 19 | 1 << 18 | 1 << 5 | 0x1f);
 		val |= (c->dma_sig & ~0x1f) << 14;
 		val |= c->dma_sig & 0x1f;
 
 		if (d->sync_mode & OMAP_DMA_SYNC_FRAME)
 			val |= 1 << 5;
-		else
-			val &= ~(1 << 5);
 
 		if (d->sync_mode & OMAP_DMA_SYNC_BLOCK)
 			val |= 1 << 18;
-		else
-			val &= ~(1 << 18);
 
 		switch (d->sync_type) {
-		case OMAP_DMA_DST_SYNC_PREFETCH:
-			val &= ~(1 << 24);	/* dest synch */
+		case OMAP_DMA_DST_SYNC_PREFETCH:/* dest synch */
 			val |= 1 << 23;		/* Prefetch */
 			break;
 		case 0:
-			val &= ~(1 << 24);	/* dest synch */
 			break;
 		default:
-			val |= 1 << 24;		/* source synch */
+			val |= 1 << 24; 	/* source synch */
 			break;
 		}
 		c->plat->dma_write(val, CCR, c->dma_ch);
 	}
 
-	c->plat->dma_write(sg->en, CEN, c->dma_ch);
-	c->plat->dma_write(sg->fn, CFN, c->dma_ch);
-
-	omap_start_dma(c->dma_ch);
-}
-
-static void omap_dma_start_desc(struct omap_chan *c)
-{
-	struct virt_dma_desc *vd = vchan_next_desc(&c->vc);
-	struct omap_desc *d;
-	uint32_t val;
-
-	if (!vd) {
-		c->desc = NULL;
-		return;
-	}
-
-	list_del(&vd->node);
-
-	c->desc = d = to_omap_dma_desc(&vd->tx);
-	c->sgidx = 0;
-
-	if (d->dir == DMA_DEV_TO_MEM) {
-		if (dma_omap1()) {
-			val = c->plat->dma_read(CSDP, c->dma_ch);
-			val &= ~(0x1f << 2);
-			val |= d->periph_port << 2;
-			c->plat->dma_write(val, CSDP, c->dma_ch);
-		}
-
-		val = c->plat->dma_read(CCR, c->dma_ch);
-		val &= ~(0x03 << 12);
-		val |= OMAP_DMA_AMODE_CONSTANT << 12;
-		c->plat->dma_write(val, CCR, c->dma_ch);
-
-		c->plat->dma_write(d->dev_addr, CSSA, c->dma_ch);
-		c->plat->dma_write(0, CSEI, c->dma_ch);
-		c->plat->dma_write(d->fi, CSFI, c->dma_ch);
-	} else {
-		if (dma_omap1()) {
-			val = c->plat->dma_read(CSDP, c->dma_ch);
-			val &= ~(0x1f << 9);
-			val |= d->periph_port << 9;
-			c->plat->dma_write(val, CSDP, c->dma_ch);
-		}
-
-		val = c->plat->dma_read(CCR, c->dma_ch);
-		val &= ~(0x03 << 14);
-		val |= OMAP_DMA_AMODE_CONSTANT << 14;
-		c->plat->dma_write(val, CCR, c->dma_ch);
-
-		c->plat->dma_write(d->dev_addr, CDSA, c->dma_ch);
-		c->plat->dma_write(0, CDEI, c->dma_ch);
-		c->plat->dma_write(d->fi, CDFI, c->dma_ch);
-	}
-
 	omap_dma_start_sg(c, d, 0);
 }
 
-- 
1.7.4.4

[PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

The following patch series moves code to setup the DMA hardware and
service interrupts from the hardware to the DMA engine driver.  This
reduces the dependency on the legacy DMA implementation.

This series does not remove the channel allocation/freeing hooks which
are used to manage the allocation of physical channels - this is the
next step in the evolution.

The patches which move the interrupt handling are currently less than
perfect since they're writing to ENABLE_L0 under a different spinlock,
and hence RFC only at the moment.

 arch/arm/mach-omap1/dma.c |  183 +++++--------
 arch/arm/mach-omap2/dma.c |  183 ++++++--------
 arch/arm/plat-omap/dma.c  |   17 +-
 drivers/dma/omap-dma.c    |  653 ++++++++++++++++++++++++++++++++++++++++-----
 include/linux/omap-dma.h  |   25 ++-
 5 files changed, 774 insertions(+), 287 deletions(-)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140102 07:11]:
> The following patch series moves code to setup the DMA hardware and
> service interrupts from the hardware to the DMA engine driver.  This
> reduces the dependency on the legacy DMA implementation.
> 
> This series does not remove the channel allocation/freeing hooks which
> are used to manage the allocation of physical channels - this is the
> next step in the evolution.
> 
> The patches which move the interrupt handling are currently less than
> perfect since they're writing to ENABLE_L0 under a different spinlock,
> and hence RFC only at the moment.

Nice to see this happening. These seem to work for me based on a quick
try on omap2+, but on omap1 the build fails:

arch/arm/mach-omap1/dma.c: In function ‘dma_write’:
arch/arm/mach-omap1/dma.c:186: error: ‘const struct omap_dma_reg’ has no member named ‘size’

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Vinod Koul]

On Thu, Jan 02, 2014 at 03:08:36PM +0000, Russell King - ARM Linux wrote:
> The following patch series moves code to setup the DMA hardware and
> service interrupts from the hardware to the DMA engine driver.  This
> reduces the dependency on the legacy DMA implementation.
Didnt the code getting removed from legacy, are there any users still of
the legacy driver in mainline?

--
~Vinod
> 
> This series does not remove the channel allocation/freeing hooks which
> are used to manage the allocation of physical channels - this is the
> next step in the evolution.
> 
> The patches which move the interrupt handling are currently less than
> perfect since they're writing to ENABLE_L0 under a different spinlock,
> and hence RFC only at the moment.
> 
>  arch/arm/mach-omap1/dma.c |  183 +++++--------
>  arch/arm/mach-omap2/dma.c |  183 ++++++--------
>  arch/arm/plat-omap/dma.c  |   17 +-
>  drivers/dma/omap-dma.c    |  653 ++++++++++++++++++++++++++++++++++++++++-----
>  include/linux/omap-dma.h  |   25 ++-
>  5 files changed, 774 insertions(+), 287 deletions(-)
> 
> -- 
> FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
> in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
> Estimate before purchase was "up to 13.2Mbit".

-- 

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Tue, Jan 07, 2014 at 05:21:11PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140102 07:11]:
> > The following patch series moves code to setup the DMA hardware and
> > service interrupts from the hardware to the DMA engine driver.  This
> > reduces the dependency on the legacy DMA implementation.
> > 
> > This series does not remove the channel allocation/freeing hooks which
> > are used to manage the allocation of physical channels - this is the
> > next step in the evolution.
> > 
> > The patches which move the interrupt handling are currently less than
> > perfect since they're writing to ENABLE_L0 under a different spinlock,
> > and hence RFC only at the moment.
> 
> Nice to see this happening. These seem to work for me based on a quick
> try on omap2+, but on omap1 the build fails:
> 
> arch/arm/mach-omap1/dma.c: In function ‘dma_write’:
> arch/arm/mach-omap1/dma.c:186: error: ‘const struct omap_dma_reg’ has no member named ‘size’

Right, needs this incremental patch:

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 3afde9628839..404f89e3eeb8 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -183,7 +183,7 @@ static inline void dma_write(u32 val, int reg, int lch)
 	addr += reg_map[reg].stride * lch;
 
 	__raw_writew(val, addr);
-	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
+	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
 		__raw_writew(val >> 16, addr + 2);
 }
 
@@ -196,7 +196,7 @@ static inline u32 dma_read(int reg, int lch)
 	addr += reg_map[reg].stride * lch;
 
 	val = __raw_readw(addr);
-	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
+	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
 		val |= __raw_readw(addr + 2) << 16;
 
 	return val;


-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Sricharan R]

On Thursday 02 January 2014 08:36 PM, Russell King - ARM Linux wrote:
> The following patch series moves code to setup the DMA hardware and
> service interrupts from the hardware to the DMA engine driver.  This
> reduces the dependency on the legacy DMA implementation.
> 
> This series does not remove the channel allocation/freeing hooks which
> are used to manage the allocation of physical channels - this is the
> next step in the evolution.
> 
> The patches which move the interrupt handling are currently less than
> perfect since they're writing to ENABLE_L0 under a different spinlock,
> and hence RFC only at the moment.
> 
>  arch/arm/mach-omap1/dma.c |  183 +++++--------
>  arch/arm/mach-omap2/dma.c |  183 ++++++--------
>  arch/arm/plat-omap/dma.c  |   17 +-
>  drivers/dma/omap-dma.c    |  653 ++++++++++++++++++++++++++++++++++++++++-----
>  include/linux/omap-dma.h  |   25 ++-
>  5 files changed, 774 insertions(+), 287 deletions(-)
> 

I tested this series on DRA7 with mmc peripheral dma and it looked
fine. Some how dmaengine test cases were not fine. But that may not
have anything to do with this series. I will check more on that and
will come back with that results as well.

Regards,
 Sricharan

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Fri, Jan 10, 2014 at 05:46:20PM +0530, Sricharan R wrote:
> I tested this series on DRA7 with mmc peripheral dma and it looked
> fine. Some how dmaengine test cases were not fine. But that may not
> have anything to do with this series. I will check more on that and
> will come back with that results as well.

Not fine in what sense?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Thu, Jan 09, 2014 at 03:24:37PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 07, 2014 at 05:21:11PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140102 07:11]:
> > > The following patch series moves code to setup the DMA hardware and
> > > service interrupts from the hardware to the DMA engine driver.  This
> > > reduces the dependency on the legacy DMA implementation.
> > > 
> > > This series does not remove the channel allocation/freeing hooks which
> > > are used to manage the allocation of physical channels - this is the
> > > next step in the evolution.
> > > 
> > > The patches which move the interrupt handling are currently less than
> > > perfect since they're writing to ENABLE_L0 under a different spinlock,
> > > and hence RFC only at the moment.
> > 
> > Nice to see this happening. These seem to work for me based on a quick
> > try on omap2+, but on omap1 the build fails:
> > 
> > arch/arm/mach-omap1/dma.c: In function ‘dma_write’:
> > arch/arm/mach-omap1/dma.c:186: error: ‘const struct omap_dma_reg’ has no member named ‘size’
> 
> Right, needs this incremental patch:
> 
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index 3afde9628839..404f89e3eeb8 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -183,7 +183,7 @@ static inline void dma_write(u32 val, int reg, int lch)
>  	addr += reg_map[reg].stride * lch;
>  
>  	__raw_writew(val, addr);
> -	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
> +	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
>  		__raw_writew(val >> 16, addr + 2);
>  }
>  
> @@ -196,7 +196,7 @@ static inline u32 dma_read(int reg, int lch)
>  	addr += reg_map[reg].stride * lch;
>  
>  	val = __raw_readw(addr);
> -	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
> +	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
>  		val |= __raw_readw(addr + 2) << 16;
>  
>  	return val;
> 

Any news on this?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> On Thu, Jan 09, 2014 at 03:24:37PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 07, 2014 at 05:21:11PM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140102 07:11]:
> > > > The following patch series moves code to setup the DMA hardware and
> > > > service interrupts from the hardware to the DMA engine driver.  This
> > > > reduces the dependency on the legacy DMA implementation.
> > > > 
> > > > This series does not remove the channel allocation/freeing hooks which
> > > > are used to manage the allocation of physical channels - this is the
> > > > next step in the evolution.
> > > > 
> > > > The patches which move the interrupt handling are currently less than
> > > > perfect since they're writing to ENABLE_L0 under a different spinlock,
> > > > and hence RFC only at the moment.
> > > 
> > > Nice to see this happening. These seem to work for me based on a quick
> > > try on omap2+, but on omap1 the build fails:
> > > 
> > > arch/arm/mach-omap1/dma.c: In function ‘dma_write’:
> > > arch/arm/mach-omap1/dma.c:186: error: ‘const struct omap_dma_reg’ has no member named ‘size’
> > 
> > Right, needs this incremental patch:
> > 
> > diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> > index 3afde9628839..404f89e3eeb8 100644
> > --- a/arch/arm/mach-omap1/dma.c
> > +++ b/arch/arm/mach-omap1/dma.c
> > @@ -183,7 +183,7 @@ static inline void dma_write(u32 val, int reg, int lch)
> >  	addr += reg_map[reg].stride * lch;
> >  
> >  	__raw_writew(val, addr);
> > -	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
> > +	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
> >  		__raw_writew(val >> 16, addr + 2);
> >  }
> >  
> > @@ -196,7 +196,7 @@ static inline u32 dma_read(int reg, int lch)
> >  	addr += reg_map[reg].stride * lch;
> >  
> >  	val = __raw_readw(addr);
> > -	if (reg_map[reg].size == OMAP_DMA_REG_2X16BIT)
> > +	if (reg_map[reg].type == OMAP_DMA_REG_2X16BIT)
> >  		val |= __raw_readw(addr + 2) << 16;
> >  
> >  	return val;
> > 
> 
> Any news on this?

Sorry for the delay, now getting this:

arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > Any news on this?
> 
> Sorry for the delay, now getting this:
> 
> arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’

Gah.  Next incremental patch:

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 404f89e3eeb8..1b1b64647def 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -344,14 +344,14 @@ static int __init omap1_system_dma_init(void)
 	if (ret) {
 		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
 			__func__, pdev->name, pdev->id);
-		goto exit_release_chan;
+		goto exit_release_d;
 	}
 
 	ret = platform_device_add(pdev);
 	if (ret) {
 		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
 			__func__, pdev->name, pdev->id);
-		goto exit_release_chan;
+		goto exit_release_d;
 	}
 
 	dma_pdev = platform_device_register_full(&omap_dma_dev_info);
@@ -364,8 +364,6 @@ static int __init omap1_system_dma_init(void)
 
 exit_release_pdev:
 	platform_device_del(pdev);
-exit_release_chan:
-	kfree(d->chan);
 exit_release_d:
 	kfree(d);
 exit_iounmap:


-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 10:57]:
> On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > > Any news on this?
> > 
> > Sorry for the delay, now getting this:
> > 
> > arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> > arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’
> 
> Gah.  Next incremental patch:

Thanks, now getting this on omap1:

# dmesg | grep -i dma
DMA: preallocated 256 KiB pool for atomic coherent allocations
OMAP DMA hardware version 1
DMA capabilities: 0000000c:00000000:01ff:003f:007f
omap-dma-engine omap-dma-engine: invalid resource
omap-dma-engine: probe of omap-dma-engine failed with error -22
mmci-omap mmci-omap.1: unable to obtain TX DMA engine channel 54
mmci-omap mmci-omap.1: unable to obtain RX DMA engine channel 55

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Mon, Jan 13, 2014 at 11:26:31AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 10:57]:
> > On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > > > Any news on this?
> > > 
> > > Sorry for the delay, now getting this:
> > > 
> > > arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> > > arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’
> > 
> > Gah.  Next incremental patch:
> 
> Thanks, now getting this on omap1:
> 
> # dmesg | grep -i dma
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> OMAP DMA hardware version 1
> DMA capabilities: 0000000c:00000000:01ff:003f:007f
> omap-dma-engine omap-dma-engine: invalid resource
> omap-dma-engine: probe of omap-dma-engine failed with error -22
> mmci-omap mmci-omap.1: unable to obtain TX DMA engine channel 54
> mmci-omap mmci-omap.1: unable to obtain RX DMA engine channel 55

Sigh... let's give it the iomem resource then:

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 1b1b64647def..4be601b638d7 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -261,6 +261,8 @@ static const struct platform_device_info omap_dma_dev_info = {
 	.name = "omap-dma-engine",
 	.id = -1,
 	.dma_mask = DMA_BIT_MASK(32),
+	.res = res,
+	.num_res = 1,
 };
 
 static struct omap_system_dma_plat_info dma_plat_info __initdata = {


-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 12:36]:
> On Mon, Jan 13, 2014 at 11:26:31AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 10:57]:
> > > On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > > > > Any news on this?
> > > > 
> > > > Sorry for the delay, now getting this:
> > > > 
> > > > arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> > > > arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’
> > > 
> > > Gah.  Next incremental patch:
> > 
> > Thanks, now getting this on omap1:
> > 
> > # dmesg | grep -i dma
> > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > OMAP DMA hardware version 1
> > DMA capabilities: 0000000c:00000000:01ff:003f:007f
> > omap-dma-engine omap-dma-engine: invalid resource
> > omap-dma-engine: probe of omap-dma-engine failed with error -22
> > mmci-omap mmci-omap.1: unable to obtain TX DMA engine channel 54
> > mmci-omap mmci-omap.1: unable to obtain RX DMA engine channel 55
> 
> Sigh... let's give it the iomem resource then:

OK, looks like adding that makes MMC card detection to fail with:

DMA timeout with device 55

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Mon, Jan 13, 2014 at 01:02:42PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 12:36]:
> > On Mon, Jan 13, 2014 at 11:26:31AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 10:57]:
> > > > On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > > > > > Any news on this?
> > > > > 
> > > > > Sorry for the delay, now getting this:
> > > > > 
> > > > > arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> > > > > arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’
> > > > 
> > > > Gah.  Next incremental patch:
> > > 
> > > Thanks, now getting this on omap1:
> > > 
> > > # dmesg | grep -i dma
> > > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > > OMAP DMA hardware version 1
> > > DMA capabilities: 0000000c:00000000:01ff:003f:007f
> > > omap-dma-engine omap-dma-engine: invalid resource
> > > omap-dma-engine: probe of omap-dma-engine failed with error -22
> > > mmci-omap mmci-omap.1: unable to obtain TX DMA engine channel 54
> > > mmci-omap mmci-omap.1: unable to obtain RX DMA engine channel 55
> > 
> > Sigh... let's give it the iomem resource then:
> 
> OK, looks like adding that makes MMC card detection to fail with:
> 
> DMA timeout with device 55

You should also see a message:

oma-dma-engine omap-dma-engine: failed to get L1 IRQ: ..

which indicates that it's falling back to the old driver for IRQ
servicing.  Can you confirm that please?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 13:13]:
> On Mon, Jan 13, 2014 at 01:02:42PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 12:36]:
> > > On Mon, Jan 13, 2014 at 11:26:31AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 10:57]:
> > > > > On Mon, Jan 13, 2014 at 09:37:45AM -0800, Tony Lindgren wrote:
> > > > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 08:48]:
> > > > > > > Any news on this?
> > > > > > 
> > > > > > Sorry for the delay, now getting this:
> > > > > > 
> > > > > > arch/arm/mach-omap1/dma.c: In function ‘omap1_system_dma_init’:
> > > > > > arch/arm/mach-omap1/dma.c:368: error: ‘struct omap_dma_dev_attr’ has no member named ‘chan’
> > > > > 
> > > > > Gah.  Next incremental patch:
> > > > 
> > > > Thanks, now getting this on omap1:
> > > > 
> > > > # dmesg | grep -i dma
> > > > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > > > OMAP DMA hardware version 1
> > > > DMA capabilities: 0000000c:00000000:01ff:003f:007f
> > > > omap-dma-engine omap-dma-engine: invalid resource
> > > > omap-dma-engine: probe of omap-dma-engine failed with error -22
> > > > mmci-omap mmci-omap.1: unable to obtain TX DMA engine channel 54
> > > > mmci-omap mmci-omap.1: unable to obtain RX DMA engine channel 55
> > > 
> > > Sigh... let's give it the iomem resource then:
> > 
> > OK, looks like adding that makes MMC card detection to fail with:
> > 
> > DMA timeout with device 55
> 
> You should also see a message:
> 
> oma-dma-engine omap-dma-engine: failed to get L1 IRQ: ..
> 
> which indicates that it's falling back to the old driver for IRQ
> servicing.  Can you confirm that please?

Yes that's correct, here are all the DMA related lines:

DMA: preallocated 256 KiB pool for atomic coherent allocations
OMAP DMA hardware version 1
DMA capabilities: 0000000c:00000000:01ff:003f:007f
omap-dma-engine omap-dma-engine: failed to get L1 IRQ: -6
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
omap-dma-engine omap-dma-engine: allocating channel 0 for 54
omap-dma-engine omap-dma-engine: allocating channel 1 for 55
DMA timeout with device 55

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Russell King - ARM Linux]

On Mon, Jan 13, 2014 at 01:21:18PM -0800, Tony Lindgren wrote:
> Yes that's correct, here are all the DMA related lines:
> 
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> OMAP DMA hardware version 1
> DMA capabilities: 0000000c:00000000:01ff:003f:007f
> omap-dma-engine omap-dma-engine: failed to get L1 IRQ: -6
> omap-dma-engine omap-dma-engine: OMAP DMA engine driver
> omap-dma-engine omap-dma-engine: allocating channel 0 for 54
> omap-dma-engine omap-dma-engine: allocating channel 1 for 55
> DMA timeout with device 55

Hmm, that's annoying, and will be annoying to debug remotely.  Would
you like a new set of patches to try bisecting to find the culpret?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [140113 13:30]:
> On Mon, Jan 13, 2014 at 01:21:18PM -0800, Tony Lindgren wrote:
> > Yes that's correct, here are all the DMA related lines:
> > 
> > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > OMAP DMA hardware version 1
> > DMA capabilities: 0000000c:00000000:01ff:003f:007f
> > omap-dma-engine omap-dma-engine: failed to get L1 IRQ: -6
> > omap-dma-engine omap-dma-engine: OMAP DMA engine driver
> > omap-dma-engine omap-dma-engine: allocating channel 0 for 54
> > omap-dma-engine omap-dma-engine: allocating channel 1 for 55
> > DMA timeout with device 55
> 
> Hmm, that's annoying, and will be annoying to debug remotely.  Would
> you like a new set of patches to try bisecting to find the culpret?

Sure that would help.

Regards,

Tony

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Sricharan R]

On Monday 13 January 2014 07:47 PM, Russell King - ARM Linux wrote:
> On Fri, Jan 10, 2014 at 05:46:20PM +0530, Sricharan R wrote:
>> I tested this series on DRA7 with mmc peripheral dma and it looked
>> fine. Some how dmaengine test cases were not fine. But that may not
>> have anything to do with this series. I will check more on that and
>> will come back with that results as well.
> 
> Not fine in what sense?
> 
Sorry for delayed response.

So in the case of dmaengine test case, it looks for channels
with DMA_MEMCPY, DMA_XOR, DMA_PQ capabilities. But the omap-dma
 device is not registered with MEMCPY capabilities, hence the
testcase fails as no channels are available.

Regards,
 Sricharan