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

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

[Peter Ujfalusi]

Hello,

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).

PS: the same errata might exist for OMAP4, but we are not able to verify it.

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

Peter Ujfalusi (1):
  OMAP3: DMA: Errata: sDMA FIFO draining does not finish

 arch/arm/plat-omap/dma.c              |   38 ++++++++++++++++++++++++++++++--
 arch/arm/plat-omap/include/plat/dma.h |    4 +++
 2 files changed, 39 insertions(+), 3 deletions(-)

--
1.7.3

[PATCH v3 1/2] 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              |    2 +-
 arch/arm/plat-omap/include/plat/dma.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index ec7eddf..7115884 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
 	 * This will always fail on ES1.0
 	 */
 	if (cpu_is_omap24xx())
-		l |= OMAP_DMA_CCR_EN;
+		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 af3a039..776ba44 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -335,6 +335,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

[PATCH v3 2/2] OMAP3: DMA: Errata: 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>
---
 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 7115884..b298361 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>
@@ -1018,8 +1019,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 completed 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 776ba44..cf66f85 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -335,6 +335,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

RE: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Peter Ujfalusi
> Sent: Friday, October 01, 2010 6:06 PM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> Subject: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not
> finish
> 
> 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).
> 
Just fyi, FIFO drain errata is not applicable for OMAP4 SDMA IP version.
Patch looks good to me.

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

> ---
>  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 7115884..b298361 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>
> @@ -1018,8 +1019,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 completed 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 776ba44..cf66f85 100644
> --- a/arch/arm/plat-omap/include/plat/dma.h
> +++ b/arch/arm/plat-omap/include/plat/dma.h
> @@ -335,6 +335,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
> 
> --
> 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 v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@nokia.com> [101001 05:27]:
>
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -1018,8 +1019,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 completed 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;

Thinking about moving to use dmaengine.c, we should not use
cpu_is_omapxxxx except during the platform init.

Can you please change this to be in u32 flags in dma.c that get set during
the init only for omap3? Then we can have something like:

#define OMAP_DMA_ERRATA_AAA	(1 << 2)
#define OMAP_DMA_ERRATA_BBB	(1 << 0)
...

Regards,

Tony

Re: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101001 09:47]:
> 
> Thinking about moving to use dmaengine.c, we should not use
> cpu_is_omapxxxx except during the platform init.
> 
> Can you please change this to be in u32 flags in dma.c that get set during
> the init only for omap3? Then we can have something like:
> 
> #define OMAP_DMA_ERRATA_AAA	(1 << 2)
> #define OMAP_DMA_ERRATA_BBB	(1 << 0)
> ...

BTW, can you also please Cc linux-arm-kernel on your patches?
That way I don't need to repost them.

Also, we might be able to get these two in as fixes.

Regards,

Tony

RE: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[G, Manjunath Kondaiah]

Peter,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Peter Ujfalusi
> Sent: Friday, October 01, 2010 6:06 PM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> Subject: [PATCH v3 1/2] omap: dma: Fix buffering disable bit 
> setting for omap24xx
> 
> 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              |    2 +-
>  arch/arm/plat-omap/include/plat/dma.h |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/dma.c 
> b/arch/arm/plat-omap/dma.c index ec7eddf..7115884 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
>  	 * This will always fail on ES1.0
>  	 */
>  	if (cpu_is_omap24xx())
> -		l |= OMAP_DMA_CCR_EN;
> +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;

This issue is applicable only for 2430ES1.0(not sure about 2420)
and it got fixed with later ES versions. 
cpu check should be replaced with:

if (cpu_is_omap2420() || (cpu_is_omap2430() && (omap_type() == OMAP2430_REV_ES1_0)))

-Manjunath

RE: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[G, Manjunath Kondaiah]

 

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of 
> Shilimkar, Santosh
> Sent: Friday, October 01, 2010 8:35 PM
> To: Peter Ujfalusi; Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> Subject: RE: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO 
> draining does not finish
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- 
> > owner@vger.kernel.org] On Behalf Of Peter Ujfalusi
> > Sent: Friday, October 01, 2010 6:06 PM
> > To: Tony Lindgren
> > Cc: linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> > Subject: [PATCH v3 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does 
> > not finish
> > 
> > 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).
> > 
> Just fyi, FIFO drain errata is not applicable for OMAP4 SDMA 
> IP version.
> Patch looks good to me.
> 
> > 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>

I can rebase this patch on top of dma hwmod changes.

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

-Manjunath

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[Jarkko Nikula]

On Sat, 2 Oct 2010 10:12:50 +0530
"G, Manjunath Kondaiah" <manjugk@ti.com> wrote:

> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
> >  	 * This will always fail on ES1.0
> >  	 */
> >  	if (cpu_is_omap24xx())
> > -		l |= OMAP_DMA_CCR_EN;
> > +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
> 
> This issue is applicable only for 2430ES1.0(not sure about 2420)
> and it got fixed with later ES versions. 
> cpu check should be replaced with:
> 
> if (cpu_is_omap2420() || (cpu_is_omap2430() && (omap_type() == OMAP2430_REV_ES1_0)))
> 
Ok, thanks for your info, I'll change this.

How about later versions of 2430? Should they use the workaround in
Patch 2/2? We experimented that also on 2420 and it seemed to help but
since the lockup was unrecovable I went thinking if 2420 has also
another issue what original workaround was trying to fix and buffering
disable was needed there.


-- 
Jarkko

RE: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[G, Manjunath Kondaiah]

> -----Original Message-----
> From: Jarkko Nikula [mailto:jhnikula@gmail.com] 
> Sent: Monday, October 04, 2010 11:13 AM
> To: G, Manjunath Kondaiah
> Cc: Peter Ujfalusi; Tony Lindgren; 
> linux-omap@vger.kernel.org; Liam Girdwood
> Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
> bit setting for omap24xx
> 
> On Sat, 2 Oct 2010 10:12:50 +0530
> "G, Manjunath Kondaiah" <manjugk@ti.com> wrote:
> 
> > > --- a/arch/arm/plat-omap/dma.c
> > > +++ b/arch/arm/plat-omap/dma.c
> > > @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch)
> > >  	 * This will always fail on ES1.0
> > >  	 */
> > >  	if (cpu_is_omap24xx())
> > > -		l |= OMAP_DMA_CCR_EN;
> > > +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
> > 
> > This issue is applicable only for 2430ES1.0(not sure about 
> 2420) and 
> > it got fixed with later ES versions.
> > cpu check should be replaced with:
> > 
> > if (cpu_is_omap2420() || (cpu_is_omap2430() && (omap_type() == 
> > OMAP2430_REV_ES1_0)))
> > 
> Ok, thanks for your info, I'll change this.
> 
> How about later versions of 2430?
Fixed in later versions ES2.0 and ES2.1

> Should they use the workaround in Patch 2/2? 
2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is not 
used with TI internal trees.

> We experimented that also on 2420 and it seemed to help but since the lockup was unrecovable I 
> went thinking if 2420 has also another issue what original 
> workaround was trying to fix and buffering disable was needed there.
I don't have any data for 2420. Based on your observation, it is better
to disable buffering for 2420.

-Manjunath

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[Peter Ujfalusi]

On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote:
> 
> 2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is
> not used with TI internal trees.
> 
> > We experimented that also on 2420 and it seemed to help but since the
> > lockup was unrecovable I went thinking if 2420 has also another issue
> > what original
> > workaround was trying to fix and buffering disable was needed there.
> 
> I don't have any data for 2420. Based on your observation, it is better
> to disable buffering for 2420.

Does the same errata number applies to OMAP2 and OMAP3 as well?
For OMAP3 the errata number is i541, but I do not know the iXYZ number for OMAP2 
class.

Thanks,
Péter
--
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 v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[G, Manjunath Kondaiah]

> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] 
> Sent: Monday, October 04, 2010 11:45 AM
> To: G, Manjunath Kondaiah
> Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; 
> Liam Girdwood
> Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
> bit setting for omap24xx
> 
> On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote:
> > 
> > 2/2 is applicable for all omap2plus except omap4. So far 2/2 
> > workaround is not used with TI internal trees.
> > 
> > > We experimented that also on 2420 and it seemed to help but since 
> > > the lockup was unrecovable I went thinking if 2420 has 
> also another 
> > > issue what original workaround was trying to fix and buffering 
> > > disable was needed there.
> > 
> > I don't have any data for 2420. Based on your observation, it is 
> > better to disable buffering for 2420.
> 
> Does the same errata number applies to OMAP2 and OMAP3 as well?
No errata numbers numbers used with TI errata documents till omap2430.
Errata numbers avaialable from omap3430 onwards.

> For OMAP3 the errata number is i541, but I do not know the 
> iXYZ number for OMAP2 class.

Being said that no errata numbers for omap2 class, it's ok to use
omap3 errata numbers for common errata(like your patch 2/2)

-Manjunath

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[Peter Ujfalusi]

On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote:
> No errata numbers numbers used with TI errata documents till omap2430.
> Errata numbers avaialable from omap3430 onwards.
> 
> > For OMAP3 the errata number is i541, but I do not know the
> > iXYZ number for OMAP2 class.
> 
> Being said that no errata numbers for omap2 class, it's ok to use
> omap3 errata numbers for common errata(like your patch 2/2)

Thanks,
we are going to use the same errata ID for OMAP2, and OMAP3, but going to use 
different workaround for them:
OMAP2: disable buffering
OMAP3: implement the workaround as it is in the errata

So, as Tony suggested, I'll add the errata handling, and
we are going to have:
DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to differentiate the different 
workarounds. We can than experiment, and we might use the OMAP3 workaround for 
OMAP2 as well.

I'll send the v4 series shortly (after testing).

-- 
Péter
--
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 v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[G, Manjunath Kondaiah]

Peter, 

> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] 
> Sent: Monday, October 04, 2010 12:46 PM
> To: G, Manjunath Kondaiah
> Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; 
> Liam Girdwood
> Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable 
> bit setting for omap24xx
> 
> On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote:
> > No errata numbers numbers used with TI errata documents 
> till omap2430.
> > Errata numbers avaialable from omap3430 onwards.
> > 
> > > For OMAP3 the errata number is i541, but I do not know the iXYZ 
> > > number for OMAP2 class.
> > 
> > Being said that no errata numbers for omap2 class, it's ok to use
> > omap3 errata numbers for common errata(like your patch 2/2)
> 
> Thanks,
> we are going to use the same errata ID for OMAP2, and OMAP3, 
> but going to use different workaround for them:
> OMAP2: disable buffering

This issue seems to be completly different from omap3 i541.
This is required to flush out fifo contents properly where as with i541, 
it requires DMA controller to be put in no mstandby mode before stoping 
DMA transfer.

> OMAP3: implement the workaround as it is in the errata
> 
> So, as Tony suggested, I'll add the errata handling, and we

If you are introducing errata handling, are you taking care of existing 
errata in DMA driver also? If not, it is better to go ahead current
implementation. DMA hwmod patches will introduce errata handling and these
changes can be rebased once it is available in mainline.


> are going to have:
> DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to

For OMAP2, you should use "DMA_ERRATA_IFRAME_BUFFERING" since it is different
type of issue.

-Manjunath 

Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx

[Peter Ujfalusi]

On Monday 04 October 2010 10:36:16 ext G, Manjunath Kondaiah wrote:
> > are going to have:
> > DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to
> 
> For OMAP2, you should use "DMA_ERRATA_IFRAME_BUFFERING" since it is
> different type of issue.

Thanks!
I'll do that.

> 
> -Manjunath

-- 
Péter
--
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