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

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

[Peter Ujfalusi]

Hello,

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              |   37 ++++++++++++++++++++++++++++++--
 arch/arm/plat-omap/include/plat/dma.h |    4 +++
 2 files changed, 38 insertions(+), 3 deletions(-)

--
1.7.3

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

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7115884..590cb47 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,38 @@ 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: 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 = sys_cf = dma_read(OCP_SYSCONFIG);
+		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 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[Jarkko Nikula]

On Fri,  1 Oct 2010 09:39:06 +0300
Peter Ujfalusi <peter.ujfalusi@nokia.com> 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>

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

[Nishanth Menon]

Peter Ujfalusi had written, on 10/01/2010 01:39 AM, the following:
[...]
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
> ---
>  arch/arm/plat-omap/dma.c              |   35 +++++++++++++++++++++++++++++++-
>  arch/arm/plat-omap/include/plat/dma.h |    3 ++
>  2 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 7115884..590cb47 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,38 @@ 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: sDMA FIFO draining does not finish */
would be informative to give the iXYZ id as well for some of these 
erratas might scale across processors.
> +	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {

does it make sense to use an dma_errata variable and populate it?
-- 
Regards,
Nishanth Menon

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

[Nishanth Menon]

Peter Ujfalusi had written, on 10/01/2010 01:39 AM, the following:
[...]
> 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;
in code comment for errata helps over time I guess.. could be my pet peeve.
> +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;

same comment -> would be nice to have erratas under a errata variable to 
help track them all..
[...]
-- 
Regards,
Nishanth Menon

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

[Peter Ujfalusi]

On Friday 01 October 2010 10:45:12 ext Nishanth Menon wrote:
...
> > -	l &= ~OMAP_DMA_CCR_EN;
> > -	dma_write(l, CCR(lch));
> > +	/* OMAP3 Errata: sDMA FIFO draining does not finish */
> 
> would be informative to give the iXYZ id as well for some of these
> erratas might scale across processors.

In TI's site I was only able to find this public ERRATA:
OMAP3530/25/15/03 Applications Processor Silicon Errata-Revs 3.1, 3.0, 2.1,&2.0 
(Rev. E)
In that document it is under: Advisory 3.1.1.192, but no iXYZ is associated with 
it. However I have another ERRATA document, which has the iXYZ associated with 
this advisory, but the first page tells that it is confidential, and under NDA 
restriction. I'm not really sure, if I should refere to that number...
But if you have the iXYZ number, which I can use, than I'm more than happy to 
add that.

> > +	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> 
> does it make sense to use an dma_errata variable and populate it?

Hmmm, the errata handling via dma_errata shall be done separately IMHO,
since if we do that, than we need to revisit other parts of the code as well, 
and replace the existing errata handling.

But yes, it would make the code much more readable, and we can easily track, 
which errata has been already addressed.

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

[Jarkko Nikula]

On Fri, 1 Oct 2010 02:47:10 -0500
Nishanth Menon <nm@ti.com> wrote:

> Peter Ujfalusi had written, on 10/01/2010 01:39 AM, the following:
> [...]
> > 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;
> in code comment for errata helps over time I guess.. could be my pet peeve.
> > +		l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
> 
Definitely. Unfortunately I don't have a 24xx TRM or errata so I cannot
check it. This workaround was introduced by a commit 1a8bfa so I think
it originated from pre-git history or from some inhouse tree.


-- 
Jarkko

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

[Nishanth Menon]

Peter Ujfalusi had written, on 10/01/2010 03:51 AM, the following:
> On Friday 01 October 2010 10:45:12 ext Nishanth Menon wrote:
> ...
>>> -	l &= ~OMAP_DMA_CCR_EN;
>>> -	dma_write(l, CCR(lch));
>>> +	/* OMAP3 Errata: sDMA FIFO draining does not finish */
>> would be informative to give the iXYZ id as well for some of these
>> erratas might scale across processors.
> 
> In TI's site I was only able to find this public ERRATA:
> OMAP3530/25/15/03 Applications Processor Silicon Errata-Revs 3.1, 3.0, 2.1,&2.0 
> (Rev. E)
> In that document it is under: Advisory 3.1.1.192, but no iXYZ is associated with 
> it. However I have another ERRATA document, which has the iXYZ associated with 
> this advisory, but the first page tells that it is confidential, and under NDA 
> restriction. I'm not really sure, if I should refere to that number...
> But if you have the iXYZ number, which I can use, than I'm more than happy to 
> add that.

I do. It is i541.

> 
>>> +	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
>> does it make sense to use an dma_errata variable and populate it?
> 
> Hmmm, the errata handling via dma_errata shall be done separately IMHO,
> since if we do that, than we need to revisit other parts of the code as well, 
> and replace the existing errata handling.
> 
> But yes, it would make the code much more readable, and we can easily track, 
> which errata has been already addressed.
> 
I suppose that is fair..

-- 
Regards,
Nishanth Menon

RE: [PATCH 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 Peter Ujfalusi
> Sent: Friday, October 01, 2010 2:22 PM
> To: Menon, Nishanth
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jarkko Nikula; 
> Liam Girdwood
> Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO 
> draining does not finish
...

> 
> > > +	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> > 
> > does it make sense to use an dma_errata variable and populate it?
> 
> Hmmm, the errata handling via dma_errata shall be done 
> separately IMHO, since if we do that, than we need to revisit 
> other parts of the code as well, and replace the existing 
> errata handling.
> 
> But yes, it would make the code much more readable, and we 
> can easily track, which errata has been already addressed.
> 

This is already done as a part of dma hwmod which is under review.

-Manjunath

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

[Nishanth Menon]

G, Manjunath Kondaiah had written, on 10/01/2010 04:29 AM, the following:
> 
>> -----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 2:22 PM
>> To: Menon, Nishanth
>> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jarkko Nikula; 
>> Liam Girdwood
>> Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO 
>> draining does not finish
> ...
> 
>>>> +	if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
>>> does it make sense to use an dma_errata variable and populate it?
>> Hmmm, the errata handling via dma_errata shall be done 
>> separately IMHO, since if we do that, than we need to revisit 
>> other parts of the code as well, and replace the existing 
>> errata handling.
>>
>> But yes, it would make the code much more readable, and we 
>> can easily track, which errata has been already addressed.
>>
> 
> This is already done as a part of dma hwmod which is under review.
> 
> -Manjunath
Apologies, but does that mean:
a) the errata i541 is handled as well as part of hwmod series?
b) the patch needs to be ported ontop of hwmod series?

-- 
Regards,
Nishanth Menon

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

[G, Manjunath Kondaiah]

 

> -----Original Message-----
> From: Menon, Nishanth 
> Sent: Friday, October 01, 2010 3:13 PM
> To: G, Manjunath Kondaiah
> Cc: Peter Ujfalusi; Tony Lindgren; 
> linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO 
> draining does not finish
> 
> G, Manjunath Kondaiah had written, on 10/01/2010 04:29 AM, 
> the following:
> > 
> >> -----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 2:22 PM
> >> To: Menon, Nishanth
> >> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jarkko Nikula; Liam 
> >> Girdwood
> >> Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO 
> draining does 
> >> not finish
> > ...
> > 
> >>>> +	if (cpu_is_omap34xx() && (l & 
> OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> >>> does it make sense to use an dma_errata variable and populate it?
> >> Hmmm, the errata handling via dma_errata shall be done separately 
> >> IMHO, since if we do that, than we need to revisit other 
> parts of the 
> >> code as well, and replace the existing errata handling.
> >>
> >> But yes, it would make the code much more readable, and we 
> can easily 
> >> track, which errata has been already addressed.
> >>
> > 
> > This is already done as a part of dma hwmod which is under review.
> > 
> > -Manjunath
> Apologies, but does that mean:
> a) the errata i541 is handled as well as part of hwmod series?
No. 
> b) the patch needs to be ported ontop of hwmod series?
Yes.

-Manjunath

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

[Peter Ujfalusi]

On Friday 01 October 2010 12:23:26 ext Nishanth Menon wrote:
> I do. It is i541.

Same number ;)
I'll resend the series and add this errata ID to the comment.

-- 
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 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[Peter Ujfalusi]

On Friday 01 October 2010 12:29:54 ext G, Manjunath Kondaiah wrote:
> > But yes, it would make the code much more readable, and we
> > can easily track, which errata has been already addressed.
> 
> This is already done as a part of dma hwmod which is under review.

OK, so we shall not bother with this in the 'legacy' code, right?

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

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

[Peter Ujfalusi]

On Friday 01 October 2010 12:45:47 ext G, Manjunath Kondaiah wrote:
> > Apologies, but does that mean:
> > a) the errata i541 is handled as well as part of hwmod series?
> 
> No.
> 
> > b) the patch needs to be ported ontop of hwmod series?
> 
> Yes.

I think these fixes should be sent for 2.6.36, and I think it might be a good 
idea to send it for .35, and .34 as well, since this problem most likely can hit 
those kernels as well.

-- 
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 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish

[G, Manjunath Kondaiah]

> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] 
> Sent: Friday, October 01, 2010 4:11 PM
> To: G, Manjunath Kondaiah
> Cc: Menon, Nishanth; Tony Lindgren; 
> linux-omap@vger.kernel.org; Jarkko Nikula; Liam Girdwood
> Subject: Re: [PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO 
> draining does not finish
> 
> On Friday 01 October 2010 12:29:54 ext G, Manjunath Kondaiah wrote:
> > > But yes, it would make the code much more readable, and we can 
> > > easily track, which errata has been already addressed.
> > 
> > This is already done as a part of dma hwmod which is under review.
> 
> OK, so we shall not bother with this in the 'legacy' code, right?
> 

That's correct but these patches needs to be ported on top of dma
driver with hwmod changes.

-Manjunath

-Manjunath

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

[Jarkko Nikula]

On Fri, 1 Oct 2010 16:39:42 +0530
"G, Manjunath Kondaiah" <manjugk@ti.com> wrote:

> > On Friday 01 October 2010 12:29:54 ext G, Manjunath Kondaiah wrote:
> > > > But yes, it would make the code much more readable, and we can 
> > > > easily track, which errata has been already addressed.
> > > 
> > > This is already done as a part of dma hwmod which is under review.
> > 
> > OK, so we shall not bother with this in the 'legacy' code, right?
> > 
> 
> That's correct but these patches needs to be ported on top of dma
> driver with hwmod changes.
> 
Priority must be opposite. Hwmod change is upcoming cleanup but these
two patches are fixing existing problem.

Problem has been there probably quite some time but we were able to see
it only after a proper use-case. Which is buffer overrun when doing
audio recording only and after the commit c12abc0 (in 2.6.32).


-- 
Jarkko

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

[Jarkko Nikula]

On Fri, 1 Oct 2010 14:43:45 +0300
Jarkko Nikula <jhnikula@gmail.com> wrote:

> Problem has been there probably quite some time but we were able to see
> it only after a proper use-case. Which is buffer overrun when doing
> audio recording only and after the commit c12abc0 (in 2.6.32).
> 
Problem is also somewhat HW specific. The N900 unit I have stalls
almost immediately after the first overrun and dma stop but I haven't
been able to reproduce it on my BeagleBoard C2. N810 typically needs a
few overruns but stalls eventually.


-- 
Jarkko

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

[Tony Lindgren]

* Jarkko Nikula <jhnikula@gmail.com> [101001 04:34]:
> On Fri, 1 Oct 2010 16:39:42 +0530
> "G, Manjunath Kondaiah" <manjugk@ti.com> wrote:
> 
> > > On Friday 01 October 2010 12:29:54 ext G, Manjunath Kondaiah wrote:
> > > > > But yes, it would make the code much more readable, and we can 
> > > > > easily track, which errata has been already addressed.
> > > > 
> > > > This is already done as a part of dma hwmod which is under review.
> > > 
> > > OK, so we shall not bother with this in the 'legacy' code, right?
> > > 
> > 
> > That's correct but these patches needs to be ported on top of dma
> > driver with hwmod changes.
> > 
> Priority must be opposite. Hwmod change is upcoming cleanup but these
> two patches are fixing existing problem.

That's right, fixes are the highest priority and we need to get those
into the mainline kernel ASAP. Otherwise there will be insane amounts
of wasted duplicate effort with people tracking the same bugs over
and over again like we've seen with omap over the years.

If you have fixes, get them into the mainline kernel.

Do not pile up fixes in some development tree where nobody will
find them.

Regards,

Tony