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

2010-10-04 Thread 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 majord...@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

2010-10-04 Thread G, Manjunath Kondaiah

Peter, 

 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@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 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@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

2010-10-04 Thread 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 majord...@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

2010-10-04 Thread 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 majord...@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

2010-10-04 Thread G, Manjunath Kondaiah


 -Original Message-
 From: Jarkko Nikula [mailto:jhnik...@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 manj...@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--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@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

2010-10-04 Thread G, Manjunath Kondaiah



 -Original Message-
 From: Peter Ujfalusi [mailto:peter.ujfal...@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




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@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

2010-10-04 Thread Jarkko Nikula
On Sat, 2 Oct 2010 10:12:50 +0530
G, Manjunath Kondaiah manj...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-10-01 Thread Peter Ujfalusi
From: Jarkko Nikula jhnik...@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.ujfal...@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 jhnik...@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@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

2010-10-01 Thread G, Manjunath Kondaiah

Peter,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@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 jhnik...@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.ujfal...@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 jhnik...@gmail.com
 Signed-off-by: Peter Ujfalusi peter.ujfal...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html