[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 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

[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".

-- 

[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".

[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".

[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".

[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

[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".

[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

[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".

[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

[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".

[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

[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".

[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

[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