[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Peter Ujfalusi]

Hello,

This v5 series is based on the v3.
The first two patch is the actual fix for the original problems without any
major change in the code (only handling the corresponding erratas in the legacy
way).
The third patch in the series is optional, and it is implementing (in one patch)
the errata handling via flags. This patch converts all errata cases to use the
introduced dma_errata variable via macros.

Tony: the first two patch need to go for 2.6.36, and if it is possible it shall
be backported to .33, .34, and .35 as well.
The final patch in this series is optional, if you feel like you can take it
(or drop it). AFAIK the upcoming hwmod changes to dma code will also have
similar feature to handle the erratas.
I'm not sure what is the schedule for the hwmod conversion of dma...

Changes since v4:
- OMAP2 Errata comment replaced with better description from
  G, Manjunath Kondaiah <manjugk@ti.com>.
- Fixed Jarkko Nikula's name in the first patch
- Based on v3 series (with suggested changes applied on top)
Changes since v3:
- OMAP2 errata is applicaple only to OMAP2420 and ES1.0 of OMAP2430
  noticed by G, Manjunath Kondaiah <manjugk@ti.com>
- use flags for errata handling
 - OMAP2 buffering disable converted to use flags
 - OMAP3 i541 is using the dma_errata flag
- Spelling fix in OMAP3 drain timeout message
Changes since v2:
- remove multiple assignment
Changes since v1:
- Errata ID added to the comment (i541)

Intro mail from v1:

The following series fixes the sDMA FIFO drain issue present for OMAP2 and
OMAP3, and covered by an errata.
For OMAP2 the omap_start_dma had a comment about this errata, but the workaround
configured wrong bit (CCR_EN instead of the correct BUFFERING_DISABLE bit).
The first patch from Jarkko Nikula <jhnikula@gmail.com> fixes this.
For OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again. The second patch implements this workaround for OMAP3.

The FIFO drain problem can be reproduced on both OMAP2 and OMAP3 while using
audio (capture case):
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/null

or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...

On OMAP2 we can not recover from this problem. The board has to be rebooted,
while OMAP3 can be recovered by reseting the sDMA channel, or introducing
unrelated sDMA activity (which takes sDMA out from Standby - but this is not
working all the time).

---
Jarkko Nikula (1):
  omap: dma: Fix buffering disable bit setting for omap24xx

Peter Ujfalusi (2):
  OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
  OMAP: DMA: Use flags for errata handling

 arch/arm/plat-omap/dma.c              |   88 +++++++++++++++++++++++++++++----
 arch/arm/plat-omap/include/plat/dma.h |    4 ++
 2 files changed, 82 insertions(+), 10 deletions(-)

--
1.7.3.1

[PATCH v5 1/3] omap: dma: Fix buffering disable bit setting for omap24xx

[Peter Ujfalusi]

From: Jarkko Nikula <jhnikula@gmail.com>

An errata workaround for omap24xx is not setting the buffering disable bit
25 what is the purpose but channel enable bit 7 instead.

Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
driver. Peter Ujfalusi <peter.ujfalusi@nokia.com> has found an issue in
recording that the DMA stall could happen if there were a buffer overrun
detected by ALSA and the DMA was stopped and restarted due that. This
problem is known to occur on both OMAP2420 and OMAP3. It can recover on
OMAP3 after dma free, dma request and reconfiguration cycle. However, on
OMAP2420 it seems that only way to recover is a reset.

Problem was not visible before the commit c12abc0. That commit changed that
the McBSP transmitter/receiver is released from reset only when needed. That
is, only enabled McBSP transmitter without transmission was able to prevent
this DMA stall problem in receiving side and underlying problem did not show
up until now. McBSP transmitter itself seems to no be reason since DMA
stall does not recover by enabling the transmission after stall.

Debugging showed that there were a DMA write active during DMA stop time and
it never completed even when restarting the DMA. Experimenting showed that
the DMA buffering disable bit could be used to avoid stalling when using
source synchronized transfers. However that could have performance hit and
OMAP3 TRM states that buffering disable is not allowed for destination
synchronized transfers so subsequent patch will implement a method to
complete DMA writes when stopping.

This patch is based on assumtion that complete lock-up on OMAP2420 is
different but related problem. I don't have access to OMAP2420 errata but
I believe this old workaround here is put for a reason but unfortunately
a wrong bit was typed and problem showed up only now.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
 arch/arm/plat-omap/dma.c              |   14 ++++++++++----
 arch/arm/plat-omap/include/plat/dma.h |    1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ec7eddf..420cef3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -996,11 +996,17 @@ void omap_start_dma(int lch)
 	l = dma_read(CCR(lch));
 
 	/*
-	 * Errata: On ES2.0 BUFFERING disable must be set.
-	 * This will always fail on ES1.0
+	 * Errata: Inter Frame DMA buffering issue (All OMAP2420 and
+	 * OMAP2430ES1.0): DMA will wrongly buffer elements if packing and
+	 * bursting is enabled. This might result in data gets stalled in
+	 * FIFO at the end of the block.
+	 * Workaround: DMA channels must have BUFFERING_DISABLED bit set to
+	 * guarantee no data will stay in the DMA FIFO in case inter frame
+	 * buffering occurs.
 	 */
-	if (cpu_is_omap24xx())
-		l |= OMAP_DMA_CCR_EN;
+	if (cpu_is_omap2420() ||
+	    (cpu_is_omap2430() && (omap_type() == OMAP2430_REV_ES1_0)))
+		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
 	l |= OMAP_DMA_CCR_EN;
 	dma_write(l, CCR(lch));
diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h
index 098f154..6f70f7c 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -337,6 +337,7 @@
 #define OMAP2_DMA_MISALIGNED_ERR_IRQ	(1 << 11)
 
 #define OMAP_DMA_CCR_EN			(1 << 7)
+#define OMAP_DMA_CCR_BUFFERING_DISABLE	(1 << 25)
 
 #define OMAP_DMA_DATA_TYPE_S8		0x00
 #define OMAP_DMA_DATA_TYPE_S16		0x01
-- 
1.7.3.1

[PATCH v5 1/3] omap: dma: Fix buffering disable bit setting for omap24xx

[G, Manjunath Kondaiah]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org 
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Peter Ujfalusi
> Sent: Tuesday, October 05, 2010 12:16 PM
> To: Tony Lindgren
> Cc: linux-omap at vger.kernel.org; Jarkko Nikula; 
> linux-arm-kernel at lists.infradead.org; Russell King
> Subject: [PATCH v5 1/3] omap: dma: Fix buffering disable bit 
> setting for omap24xx
> 
> From: Jarkko Nikula <jhnikula@gmail.com>
...
>  
>  	/*
> -	 * Errata: On ES2.0 BUFFERING disable must be set.
> -	 * This will always fail on ES1.0
> +	 * Errata: Inter Frame DMA buffering issue (All OMAP2420 and
> +	 * OMAP2430ES1.0): DMA will wrongly buffer elements if 
> packing and
> +	 * bursting is enabled. This might result in data gets 
> stalled in
> +	 * FIFO at the end of the block.
> +	 * Workaround: DMA channels must have 
> BUFFERING_DISABLED bit set to
> +	 * guarantee no data will stay in the DMA FIFO in case 
> inter frame
> +	 * buffering occurs.
>  	 */
> -	if (cpu_is_omap24xx())
> -		l |= OMAP_DMA_CCR_EN;
> +	if (cpu_is_omap2420() ||
> +	    (cpu_is_omap2430() && (omap_type() == OMAP2430_REV_ES1_0)))
> +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;

Acked-by: G, Manjunath Kondaiah <manjugk@ti.com>

-Manjunath

[PATCH v5 2/3] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

[Peter Ujfalusi]

Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.

The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/null

or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...

In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).

The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by : G, Manjunath Kondaiah <manjugk@ti.com>
---
 arch/arm/plat-omap/dma.c              |   36 +++++++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/dma.h |    3 ++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 420cef3..f5c5b8d 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -30,6 +30,7 @@
 #include <linux/irq.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <linux/delay.h>
 
 #include <asm/system.h>
 #include <mach/hardware.h>
@@ -1024,8 +1025,39 @@ void omap_stop_dma(int lch)
 		dma_write(0, CICR(lch));
 
 	l = dma_read(CCR(lch));
-	l &= ~OMAP_DMA_CCR_EN;
-	dma_write(l, CCR(lch));
+	/* OMAP3 Errata i541: sDMA FIFO draining does not finish */
+	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+		int i = 0;
+		u32 sys_cf;
+
+		/* Configure No-Standby */
+		l = dma_read(OCP_SYSCONFIG);
+		sys_cf = l;
+		l &= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
+		l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
+		dma_write(l , OCP_SYSCONFIG);
+
+		l = dma_read(CCR(lch));
+		l &= ~OMAP_DMA_CCR_EN;
+		dma_write(l, CCR(lch));
+
+		/* Wait for sDMA FIFO drain */
+		l = dma_read(CCR(lch));
+		while (i < 100 && (l & (OMAP_DMA_CCR_RD_ACTIVE |
+					OMAP_DMA_CCR_WR_ACTIVE))) {
+			udelay(5);
+			i++;
+			l = dma_read(CCR(lch));
+		}
+		if (i >= 100)
+			printk(KERN_ERR "DMA drain did not complete on "
+					"lch %d\n", lch);
+		/* Restore OCP_SYSCONFIG */
+		dma_write(sys_cf, OCP_SYSCONFIG);
+	} else {
+		l &= ~OMAP_DMA_CCR_EN;
+		dma_write(l, CCR(lch));
+	}
 
 	if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
 		int next_lch, cur_lch = lch;
diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h
index 6f70f7c..0cce4ca 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -337,6 +337,9 @@
 #define OMAP2_DMA_MISALIGNED_ERR_IRQ	(1 << 11)
 
 #define OMAP_DMA_CCR_EN			(1 << 7)
+#define OMAP_DMA_CCR_RD_ACTIVE		(1 << 9)
+#define OMAP_DMA_CCR_WR_ACTIVE		(1 << 10)
+#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC	(1 << 24)
 #define OMAP_DMA_CCR_BUFFERING_DISABLE	(1 << 25)
 
 #define OMAP_DMA_DATA_TYPE_S8		0x00
-- 
1.7.3.1

[PATCH v5 2/3] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

[Adrian Hunter]

On 05/10/10 09:45, Peter Ujfalusi wrote:
> Implement the suggested workaround for OMAP3 regarding to sDMA draining
> issue, when the channel is disabled on the fly.
> This errata affects the following configuration:
> sDMA transfer is source synchronized
> Buffering is enabled
> SmartStandby is selected.
>
> The issue can be easily reproduced by creating overrun situation while
> recording audio.
> Either introduce load to the CPU:
> nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat>  /dev/null&  \
> dd if=/dev/urandom of=/dev/null
>
> or suspending the arecord, and resuming it:
> arecord -D hw:0 -M -B 10000 -F 5000 -f dat>  /dev/null
> CTRL+Z; fg; CTRL+Z; fg; ...
>
> In case of overrun audio stops DMA, and restarts it (without reseting
> the sDMA channel). When we hit this errata in stop case (sDMA drain did
> not complete), at the coming start the sDMA will not going to be
> operational (it is still draining).
> This leads to DMA stall condition.
> On OMAP3 we can recover with sDMA channel reset, it has been observed
> that by introducing unrelated sDMA activity might also help (reading
> from MMC for example).
>
> The same errata exists for OMAP2, where the suggestion is to disable the
> buffering to avoid this type of error.
> On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
> the channel, and wait for the drain to finish, than configure sDMA to
> SmartStandby again.
>
> Signed-off-by: Peter Ujfalusi<peter.ujfalusi@nokia.com>
> Acked-by: Jarkko Nikula<jhnikula@gmail.com>
> Acked-by : Santosh Shilimkar<santosh.shilimkar@ti.com>
> Acked-by : G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/plat-omap/dma.c              |   36 +++++++++++++++++++++++++++++++-
>   arch/arm/plat-omap/include/plat/dma.h |    3 ++
>   2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 420cef3..f5c5b8d 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -30,6 +30,7 @@
>   #include<linux/irq.h>
>   #include<linux/io.h>
>   #include<linux/slab.h>
> +#include<linux/delay.h>
>
>   #include<asm/system.h>
>   #include<mach/hardware.h>
> @@ -1024,8 +1025,39 @@ void omap_stop_dma(int lch)
>   		dma_write(0, CICR(lch));
>
>   	l = dma_read(CCR(lch));
> -	l&= ~OMAP_DMA_CCR_EN;
> -	dma_write(l, CCR(lch));
> +	/* OMAP3 Errata i541: sDMA FIFO draining does not finish */

Is this also needed in omap_free_dma or omap_clear_dma?

> +	if (cpu_is_omap34xx()&&  (l&  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> +		int i = 0;
> +		u32 sys_cf;
> +
> +		/* Configure No-Standby */
> +		l = dma_read(OCP_SYSCONFIG);
> +		sys_cf = l;
> +		l&= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
> +		l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
> +		dma_write(l , OCP_SYSCONFIG);

Are accesses of OCP_SYSCONFIG synchronised?

> +
> +		l = dma_read(CCR(lch));
> +		l&= ~OMAP_DMA_CCR_EN;
> +		dma_write(l, CCR(lch));
> +
> +		/* Wait for sDMA FIFO drain */
> +		l = dma_read(CCR(lch));
> +		while (i<  100&&  (l&  (OMAP_DMA_CCR_RD_ACTIVE |
> +					OMAP_DMA_CCR_WR_ACTIVE))) {
> +			udelay(5);
> +			i++;
> +			l = dma_read(CCR(lch));
> +		}
> +		if (i>= 100)
> +			printk(KERN_ERR "DMA drain did not complete on "
> +					"lch %d\n", lch);
> +		/* Restore OCP_SYSCONFIG */
> +		dma_write(sys_cf, OCP_SYSCONFIG);
> +	} else {
> +		l&= ~OMAP_DMA_CCR_EN;
> +		dma_write(l, CCR(lch));
> +	}
>
>   	if (!omap_dma_in_1510_mode()&&  dma_chan[lch].next_lch != -1) {
>   		int next_lch, cur_lch = lch;
> diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h
> index 6f70f7c..0cce4ca 100644
> --- a/arch/arm/plat-omap/include/plat/dma.h
> +++ b/arch/arm/plat-omap/include/plat/dma.h
> @@ -337,6 +337,9 @@
>   #define OMAP2_DMA_MISALIGNED_ERR_IRQ	(1<<  11)
>
>   #define OMAP_DMA_CCR_EN			(1<<  7)
> +#define OMAP_DMA_CCR_RD_ACTIVE		(1<<  9)
> +#define OMAP_DMA_CCR_WR_ACTIVE		(1<<  10)
> +#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC	(1<<  24)
>   #define OMAP_DMA_CCR_BUFFERING_DISABLE	(1<<  25)
>
>   #define OMAP_DMA_DATA_TYPE_S8		0x00

[PATCH v5 2/3] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

[Adrian Hunter]

On 05/10/10 09:45, Peter Ujfalusi wrote:
> Implement the suggested workaround for OMAP3 regarding to sDMA draining
> issue, when the channel is disabled on the fly.
> This errata affects the following configuration:
> sDMA transfer is source synchronized
> Buffering is enabled
> SmartStandby is selected.
>
> The issue can be easily reproduced by creating overrun situation while
> recording audio.
> Either introduce load to the CPU:
> nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat>  /dev/null&  \
> dd if=/dev/urandom of=/dev/null
>
> or suspending the arecord, and resuming it:
> arecord -D hw:0 -M -B 10000 -F 5000 -f dat>  /dev/null
> CTRL+Z; fg; CTRL+Z; fg; ...
>
> In case of overrun audio stops DMA, and restarts it (without reseting
> the sDMA channel). When we hit this errata in stop case (sDMA drain did
> not complete), at the coming start the sDMA will not going to be
> operational (it is still draining).
> This leads to DMA stall condition.
> On OMAP3 we can recover with sDMA channel reset, it has been observed
> that by introducing unrelated sDMA activity might also help (reading
> from MMC for example).
>
> The same errata exists for OMAP2, where the suggestion is to disable the
> buffering to avoid this type of error.
> On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
> the channel, and wait for the drain to finish, than configure sDMA to
> SmartStandby again.
>
> Signed-off-by: Peter Ujfalusi<peter.ujfalusi@nokia.com>
> Acked-by: Jarkko Nikula<jhnikula@gmail.com>
> Acked-by : Santosh Shilimkar<santosh.shilimkar@ti.com>
> Acked-by : G, Manjunath Kondaiah<manjugk@ti.com>
> ---
>   arch/arm/plat-omap/dma.c              |   36 +++++++++++++++++++++++++++++++-
>   arch/arm/plat-omap/include/plat/dma.h |    3 ++
>   2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 420cef3..f5c5b8d 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -30,6 +30,7 @@
>   #include<linux/irq.h>
>   #include<linux/io.h>
>   #include<linux/slab.h>
> +#include<linux/delay.h>
>
>   #include<asm/system.h>
>   #include<mach/hardware.h>
> @@ -1024,8 +1025,39 @@ void omap_stop_dma(int lch)
>   		dma_write(0, CICR(lch));
>
>   	l = dma_read(CCR(lch));
> -	l&= ~OMAP_DMA_CCR_EN;
> -	dma_write(l, CCR(lch));
> +	/* OMAP3 Errata i541: sDMA FIFO draining does not finish */

Is this also needed in omap_free_dma or omap_clear_dma?

> +	if (cpu_is_omap34xx()&&  (l&  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> +		int i = 0;
> +		u32 sys_cf;
> +
> +		/* Configure No-Standby */
> +		l = dma_read(OCP_SYSCONFIG);
> +		sys_cf = l;
> +		l&= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
> +		l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
> +		dma_write(l , OCP_SYSCONFIG);

Are accesses of OCP_SYSCONFIG synchronised?

> +
> +		l = dma_read(CCR(lch));
> +		l&= ~OMAP_DMA_CCR_EN;
> +		dma_write(l, CCR(lch));
> +
> +		/* Wait for sDMA FIFO drain */
> +		l = dma_read(CCR(lch));
> +		while (i<  100&&  (l&  (OMAP_DMA_CCR_RD_ACTIVE |
> +					OMAP_DMA_CCR_WR_ACTIVE))) {
> +			udelay(5);
> +			i++;
> +			l = dma_read(CCR(lch));
> +		}
> +		if (i>= 100)
> +			printk(KERN_ERR "DMA drain did not complete on "
> +					"lch %d\n", lch);
> +		/* Restore OCP_SYSCONFIG */
> +		dma_write(sys_cf, OCP_SYSCONFIG);
> +	} else {
> +		l&= ~OMAP_DMA_CCR_EN;
> +		dma_write(l, CCR(lch));
> +	}
>
>   	if (!omap_dma_in_1510_mode()&&  dma_chan[lch].next_lch != -1) {
>   		int next_lch, cur_lch = lch;
> diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h
> index 6f70f7c..0cce4ca 100644
> --- a/arch/arm/plat-omap/include/plat/dma.h
> +++ b/arch/arm/plat-omap/include/plat/dma.h
> @@ -337,6 +337,9 @@
>   #define OMAP2_DMA_MISALIGNED_ERR_IRQ	(1<<  11)
>
>   #define OMAP_DMA_CCR_EN			(1<<  7)
> +#define OMAP_DMA_CCR_RD_ACTIVE		(1<<  9)
> +#define OMAP_DMA_CCR_WR_ACTIVE		(1<<  10)
> +#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC	(1<<  24)
>   #define OMAP_DMA_CCR_BUFFERING_DISABLE	(1<<  25)
>
>   #define OMAP_DMA_DATA_TYPE_S8		0x00

[PATCH v5 2/3] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

[Paul Walmsley]

Hello Adrian,

On Wed, 10 Nov 2010, Adrian Hunter wrote:

> On 05/10/10 09:45, Peter Ujfalusi wrote:
> 
> > +	if (cpu_is_omap34xx()&&  (l&  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> > +		int i = 0;
> > +		u32 sys_cf;
> > +
> > +		/* Configure No-Standby */
> > +		l = dma_read(OCP_SYSCONFIG);
> > +		sys_cf = l;
> > +		l&= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
> > +		l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
> > +		dma_write(l , OCP_SYSCONFIG);
> 
> Are accesses of OCP_SYSCONFIG synchronised?

Do you mean, with respect to later reads and writes from the SDMA device?  
If so, then yes, later reads and writes to the SDMA are guaranteed to 
complete in order.  But perhaps I am misunderstanding what you mean?


- Paul

[PATCH v5 2/3] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish

[Adrian Hunter]

On 11/11/10 01:30, ext Paul Walmsley wrote:
> Hello Adrian,
>
> On Wed, 10 Nov 2010, Adrian Hunter wrote:
>
>> On 05/10/10 09:45, Peter Ujfalusi wrote:
>>
>>> +	if (cpu_is_omap34xx()&&   (l&   OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
>>> +		int i = 0;
>>> +		u32 sys_cf;
>>> +
>>> +		/* Configure No-Standby */
>>> +		l = dma_read(OCP_SYSCONFIG);
>>> +		sys_cf = l;
>>> +		l&= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
>>> +		l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
>>> +		dma_write(l , OCP_SYSCONFIG);
>>
>> Are accesses of OCP_SYSCONFIG synchronised?
>
> Do you mean, with respect to later reads and writes from the SDMA device?
> If so, then yes, later reads and writes to the SDMA are guaranteed to
> complete in order.  But perhaps I am misunderstanding what you mean?

I just meant it looks racy e.g.  two threads call omap_dma_stop() (or
another function that changes OCP_SYSCONFIG) at the same time

[PATCH v5 3/3] OMAP: DMA: Use flags for errata handling

[Peter Ujfalusi]

Change the errata handling to use flags instead of cpu_is_*
cpu_class_* in the code.
The errata flags are initialized at init time.
In runtime we are using the dma_errata variable (via the
IS_DMA_ERRATA macro) to execute the required errata workaround.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
 arch/arm/plat-omap/dma.c |   44 +++++++++++++++++++++++++++++++++++++-------
 1 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..2f7fba0 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -147,6 +147,20 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = {
 	INT_1610_DMA_CH14, INT_1610_DMA_CH15, INT_DMA_LCD
 };
 
+/* Errata handling */
+u32 dma_errata;
+#define IS_DMA_ERRATA(id)		(dma_errata & (id))
+#define SET_DMA_ERRATA(id)		(dma_errata | (id))
+
+/* Errata: Inter Frame DMA buffering issue */
+#define DMA_ERRATA_IFRAME_BUFFERING	(1 << 0)
+/* Errata: DMA may hang when several channels are used in parallel */
+#define DMA_ERRATA_PARALLEL_CHANNELS	(1 << 1)
+/* Errata i378: sDMA Channel is not disabled after a transaction error */
+#define DMA_ERRATA_i378			(1 << 2)
+/* Errata i541: sDMA FIFO draining does not finish */
+#define DMA_ERRATA_i541			(1 << 3)
+
 static inline void disable_lnk(int lch);
 static void omap_disable_channel_irq(int lch);
 static inline void omap_enable_channel_irq(int lch);
@@ -985,9 +999,7 @@ void omap_start_dma(int lch)
 
 			cur_lch = next_lch;
 		} while (next_lch != -1);
-	} else if (cpu_is_omap242x() ||
-		(cpu_is_omap243x() &&  omap_type() <= OMAP2430_REV_ES1_0)) {
-
+	} else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS)) {
 		/* Errata: Need to write lch even if not using chaining */
 		dma_write(lch, CLNK_CTRL(lch));
 	}
@@ -1005,8 +1017,7 @@ void omap_start_dma(int lch)
 	 * guarantee no data will stay in the DMA FIFO in case inter frame
 	 * buffering occurs.
 	 */
-	if (cpu_is_omap2420() ||
-	    (cpu_is_omap2430() && (omap_type() == OMAP2430_REV_ES1_0)))
+	if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
 		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
 	l |= OMAP_DMA_CCR_EN;
@@ -1026,7 +1037,8 @@ void omap_stop_dma(int lch)
 
 	l = dma_read(CCR(lch));
 	/* OMAP3 Errata i541: sDMA FIFO draining does not finish */
-	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+	if (IS_DMA_ERRATA(DMA_ERRATA_i541) &&
+	    (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
 		int i = 0;
 		u32 sys_cf;
 
@@ -1960,7 +1972,7 @@ static int omap2_dma_handle_ch(int ch)
 	if (unlikely(status & OMAP2_DMA_TRANS_ERR_IRQ)) {
 		printk(KERN_INFO "DMA transaction error with device %d\n",
 		       dma_chan[ch].dev_id);
-		if (cpu_class_is_omap2()) {
+		if (IS_DMA_ERRATA(DMA_ERRATA_i378)) {
 			/*
 			 * Errata: sDMA Channel is not disabled
 			 * after a transaction error. So we explicitely
@@ -2079,6 +2091,22 @@ void omap_dma_global_context_restore(void)
 
 /*----------------------------------------------------------------------------*/
 
+/* Initialize sDMA errata flags */
+static void dma_errata_configure(void)
+{
+	if (cpu_is_omap242x() ||
+	    (cpu_is_omap243x() && (omap_type() == OMAP2430_REV_ES1_0))) {
+		SET_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING);
+		SET_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS);
+	}
+
+	if (cpu_class_is_omap2())
+		SET_DMA_ERRATA(DMA_ERRATA_i378);
+
+	if (cpu_is_omap34xx())
+		SET_DMA_ERRATA(DMA_ERRATA_i541);
+}
+
 static int __init omap_init_dma(void)
 {
 	unsigned long base;
@@ -2101,6 +2129,8 @@ static int __init omap_init_dma(void)
 		return -ENODEV;
 	}
 
+	dma_errata_configure();
+
 	omap_dma_base = ioremap(base, SZ_4K);
 	BUG_ON(!omap_dma_base);
 
-- 
1.7.3.1

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[G, Manjunath Kondaiah]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org 
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Peter Ujfalusi
> Sent: Tuesday, October 05, 2010 12:16 PM
> To: Tony Lindgren
> Cc: linux-omap at vger.kernel.org; Jarkko Nikula; 
> linux-arm-kernel at lists.infradead.org; Russell King
> Subject: [PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes
> 
> Hello,
> 
> This v5 series is based on the v3.
> The first two patch is the actual fix for the original 
> problems without any major change in the code (only handling 
> the corresponding erratas in the legacy way).
> The third patch in the series is optional, and it is 
> implementing (in one patch) the errata handling via flags. 
> This patch converts all errata cases to use the introduced 
> dma_errata variable via macros.
> 
> Tony: the first two patch need to go for 2.6.36, and if it is 
> possible it shall be backported to .33, .34, and .35 as well.
> The final patch in this series is optional, if you feel like 
> you can take it 
NAK
>(or drop it). 
ACK
>AFAIK the upcoming hwmod 
> changes to dma code will also have similar feature to handle 
> the erratas.
> I'm not sure what is the schedule for the hwmod conversion of dma...
v2 version of dma hwmod patches already exists in LOML which is 
already covering errata handling feature. I can rebase 1/3 and 2/3 
patches into dma hwmod errata handling.

v3 dma hwmod version will be posted soon once these fixes are rebased
and tested on all applicable omap's.

IOW, the errata handling feature comes along with all applicable erratas
ported with dma v3 hwmod series instead of having your patch 3/3 which is 
partially implemented.

-Manjunath

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@nokia.com> [101004 23:37]:
> Hello,
> 
> This v5 series is based on the v3.
> The first two patch is the actual fix for the original problems without any
> major change in the code (only handling the corresponding erratas in the legacy
> way).
> The third patch in the series is optional, and it is implementing (in one patch)
> the errata handling via flags. This patch converts all errata cases to use the
> introduced dma_errata variable via macros.
> 
> Tony: the first two patch need to go for 2.6.36, and if it is possible it shall
> be backported to .33, .34, and .35 as well.

OK, I'll the first two into omap-fixes.

> The final patch in this series is optional, if you feel like you can take it
> (or drop it). AFAIK the upcoming hwmod changes to dma code will also have
> similar feature to handle the erratas.
> I'm not sure what is the schedule for the hwmod conversion of dma...

Let's queue this clean-up with the hwmod patches then.

Regards,

Tony

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101005 11:07]:
> * Peter Ujfalusi <peter.ujfalusi@nokia.com> [101004 23:37]:
> > Hello,
> > 
> > This v5 series is based on the v3.
> > The first two patch is the actual fix for the original problems without any
> > major change in the code (only handling the corresponding erratas in the legacy
> > way).
> > The third patch in the series is optional, and it is implementing (in one patch)
> > the errata handling via flags. This patch converts all errata cases to use the
> > introduced dma_errata variable via macros.
> > 
> > Tony: the first two patch need to go for 2.6.36, and if it is possible it shall
> > be backported to .33, .34, and .35 as well.
> 
> OK, I'll the first two into omap-fixes.

Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just
queueing these for 2.6.37 for the following reasons:

- The 24xx patch is a fix for commit c12abc0 that's was merged over a
  year ago. We've lived with it for over a year now. What difference does
  extra few more months make if we have it in 2.6.37 instead of 2.6.36?

- The second 34xx fix seems to happen only when disabling DMA on the fly.
  Again, we've had support for 34xx in the mainline kernel for a few
  years, and we're not seeing unrecoverable issues with MMC or USB or
  any other code calling omap_dma_stop().

Sure these fix major issues with the DMA, but are these really critical
for 2.6.36?

So if you really want me to argue for merging these into 2.6.36, please let
me know some oops causing cases or data corruption that happens without
these patches.

Cheers,

Tony

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Peter Ujfalusi]

Sorry, I did missed this mail...

On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote:

> Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just
> queueing these for 2.6.37 for the following reasons:
> 
> - The 24xx patch is a fix for commit c12abc0 that's was merged over a
>   year ago. We've lived with it for over a year now. What difference does
>   extra few more months make if we have it in 2.6.37 instead of 2.6.36?
> 
> - The second 34xx fix seems to happen only when disabling DMA on the fly.
>   Again, we've had support for 34xx in the mainline kernel for a few
>   years, and we're not seeing unrecoverable issues with MMC or USB or
>   any other code calling omap_dma_stop().
> 
> Sure these fix major issues with the DMA, but are these really critical
> for 2.6.36?
> 
> So if you really want me to argue for merging these into 2.6.36, please let
> me know some oops causing cases or data corruption that happens without
> these patches.

Well 2.6.36 is released.
I still would like to see this to be part of the 2.6.36.1 release. We can 
reproduce the DMA error in 2.6.36 with audio.

Tony: can you make sure it is going to part of 2.6.36.1?

Thanks,
P?ter

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Tony Lindgren]

Hi Greg,

Considering below..

* Peter Ujfalusi <peter.ujfalusi@nokia.com> [101021 02:56]:
> Sorry, I did missed this mail...
> 
> On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote:
> 
> > Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just
> > queueing these for 2.6.37 for the following reasons:
> > 
> > - The 24xx patch is a fix for commit c12abc0 that's was merged over a
> >   year ago. We've lived with it for over a year now. What difference does
> >   extra few more months make if we have it in 2.6.37 instead of 2.6.36?
> > 
> > - The second 34xx fix seems to happen only when disabling DMA on the fly.
> >   Again, we've had support for 34xx in the mainline kernel for a few
> >   years, and we're not seeing unrecoverable issues with MMC or USB or
> >   any other code calling omap_dma_stop().
> > 
> > Sure these fix major issues with the DMA, but are these really critical
> > for 2.6.36?
> > 
> > So if you really want me to argue for merging these into 2.6.36, please let
> > me know some oops causing cases or data corruption that happens without
> > these patches.
> 
> Well 2.6.36 is released.
> I still would like to see this to be part of the 2.6.36.1 release. We can 
> reproduce the DMA error in 2.6.36 with audio.
> 
> Tony: can you make sure it is going to part of 2.6.36.1?

..are you interested in these two patches for stable kernels?

The two patches in question are the following mainline commits:

3e57f1626b5febe5cc99aa6870377deef3ae03cc
0e4905c0199d683497833be60a428c784d7575b8

Regards,

Tony

[PATCH v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes

[Greg KH]

On Fri, Nov 05, 2010 at 02:29:02PM -0700, Tony Lindgren wrote:
> Hi Greg,
> 
> Considering below..
> 
> * Peter Ujfalusi <peter.ujfalusi@nokia.com> [101021 02:56]:
> > Sorry, I did missed this mail...
> > 
> > On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote:
> > 
> > > Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just
> > > queueing these for 2.6.37 for the following reasons:
> > > 
> > > - The 24xx patch is a fix for commit c12abc0 that's was merged over a
> > >   year ago. We've lived with it for over a year now. What difference does
> > >   extra few more months make if we have it in 2.6.37 instead of 2.6.36?
> > > 
> > > - The second 34xx fix seems to happen only when disabling DMA on the fly.
> > >   Again, we've had support for 34xx in the mainline kernel for a few
> > >   years, and we're not seeing unrecoverable issues with MMC or USB or
> > >   any other code calling omap_dma_stop().
> > > 
> > > Sure these fix major issues with the DMA, but are these really critical
> > > for 2.6.36?
> > > 
> > > So if you really want me to argue for merging these into 2.6.36, please let
> > > me know some oops causing cases or data corruption that happens without
> > > these patches.
> > 
> > Well 2.6.36 is released.
> > I still would like to see this to be part of the 2.6.36.1 release. We can 
> > reproduce the DMA error in 2.6.36 with audio.
> > 
> > Tony: can you make sure it is going to part of 2.6.36.1?
> 
> ..are you interested in these two patches for stable kernels?
> 
> The two patches in question are the following mainline commits:
> 
> 3e57f1626b5febe5cc99aa6870377deef3ae03cc
> 0e4905c0199d683497833be60a428c784d7575b8

Now queued up, thanks.

greg k-h