* [PATCH v2 0/2] OMAP2/3: DMA: FIFO drain errata fixes @ 2010-10-01 11:04 Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 1/2] omap: dma: Fix buffering disable bit setting for omap24xx Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish Peter Ujfalusi 0 siblings, 2 replies; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 11:04 UTC (permalink / raw) To: Tony Lindgren; +Cc: linux-omap, Jarkko Nikula, Liam Girdwood, Nishanth Menon Hello, 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 | 37 ++++++++++++++++++++++++++++++-- arch/arm/plat-omap/include/plat/dma.h | 4 +++ 2 files changed, 38 insertions(+), 3 deletions(-) -- 1.7.3 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 1/2] omap: dma: Fix buffering disable bit setting for omap24xx 2010-10-01 11:04 [PATCH v2 0/2] OMAP2/3: DMA: FIFO drain errata fixes Peter Ujfalusi @ 2010-10-01 11:04 ` Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish Peter Ujfalusi 1 sibling, 0 replies; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 11:04 UTC (permalink / raw) To: Tony Lindgren; +Cc: linux-omap, Jarkko Nikula, Liam Girdwood, Nishanth Menon 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 11:04 [PATCH v2 0/2] OMAP2/3: DMA: FIFO drain errata fixes Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 1/2] omap: dma: Fix buffering disable bit setting for omap24xx Peter Ujfalusi @ 2010-10-01 11:04 ` Peter Ujfalusi 2010-10-01 11:50 ` David Cohen 1 sibling, 1 reply; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 11:04 UTC (permalink / raw) To: Tony Lindgren; +Cc: linux-omap, Jarkko Nikula, Liam Girdwood, Nishanth Menon 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..287a00e 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 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 = 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 11:04 ` [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish Peter Ujfalusi @ 2010-10-01 11:50 ` David Cohen 2010-10-01 12:16 ` Peter Ujfalusi 0 siblings, 1 reply; 9+ messages in thread From: David Cohen @ 2010-10-01 11:50 UTC (permalink / raw) To: ext Peter Ujfalusi Cc: Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Nishanth Menon Hi, On Fri, Oct 01, 2010 at 01:04:55PM +0200, ext 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> > --- > 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..287a00e 100644 > --- a/arch/arm/plat-omap/dma.c > +++ b/arch/arm/plat-omap/dma.c [snip] > + l = sys_cf = dma_read(OCP_SYSCONFIG); Shouldn't it be avoided? Regards, David > + 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 11:50 ` David Cohen @ 2010-10-01 12:16 ` Peter Ujfalusi 2010-10-01 12:17 ` David Cohen 2010-10-01 12:24 ` Felipe Balbi 0 siblings, 2 replies; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 12:16 UTC (permalink / raw) To: David Cohen Cc: Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Nishanth Menon On Friday 01 October 2010 14:50:37 David Cohen wrote: > > > + l = sys_cf = dma_read(OCP_SYSCONFIG); > > Shouldn't it be avoided? I'm restoring the OCP_SYSCONFIG register later on, and reusing 'l' here to avoid confusing expression when moving the sDMA to NoStandby. I could as well introduce other variable for this... > > Regards, > > David > > > + l &= ~DMA_SYSCONFIG_MIDLEMODE_MASK; > > + l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE); > > + dma_write(l , OCP_SYSCONFIG); I could have: dma_write((sys_fc & (~DMA_SYSCONFIG_MIDLEMODE_MASK)) | DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE), OCP_SYSCONFIG); Than I do not need the re-read the CCR, but it looks a bit messy. > > + > > + l = dma_read(CCR(lch)); > > + l &= ~OMAP_DMA_CCR_EN; > > + dma_write(l, CCR(lch)); > > + ... > > + /* Restore OCP_SYSCONFIG */ > > + dma_write(sys_cf, OCP_SYSCONFIG); -- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 12:16 ` Peter Ujfalusi @ 2010-10-01 12:17 ` David Cohen 2010-10-01 12:43 ` Peter Ujfalusi 2010-10-01 12:24 ` Felipe Balbi 1 sibling, 1 reply; 9+ messages in thread From: David Cohen @ 2010-10-01 12:17 UTC (permalink / raw) To: Peter Ujfalusi Cc: Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Nishanth Menon On Fri, Oct 01, 2010 at 02:16:53PM +0200, Peter Ujfalusi wrote: > On Friday 01 October 2010 14:50:37 David Cohen wrote: > > > > > + l = sys_cf = dma_read(OCP_SYSCONFIG); > > > > Shouldn't it be avoided? > > I'm restoring the OCP_SYSCONFIG register later on, and reusing 'l' here to avoid > confusing expression when moving the sDMA to NoStandby. > I could as well introduce other variable for this... No problem with those two variables, but you're doing multiple assignments in one line. You could do something like this: l = dma_read(OCP_SYSCONFIG); sys_cf = l; Regards, David ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 12:17 ` David Cohen @ 2010-10-01 12:43 ` Peter Ujfalusi 0 siblings, 0 replies; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 12:43 UTC (permalink / raw) To: David Cohen Cc: Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Nishanth Menon On Friday 01 October 2010 15:17:16 David Cohen wrote: > No problem with those two variables, but you're doing multiple > assignments in one line. You could do something like this: > > l = dma_read(OCP_SYSCONFIG); > sys_cf = l; I have sent the v3 with this fixed. Thanks you, 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 12:16 ` Peter Ujfalusi 2010-10-01 12:17 ` David Cohen @ 2010-10-01 12:24 ` Felipe Balbi 2010-10-01 12:30 ` Peter Ujfalusi 1 sibling, 1 reply; 9+ messages in thread From: Felipe Balbi @ 2010-10-01 12:24 UTC (permalink / raw) To: Peter Ujfalusi Cc: David Cohen, Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Menon, Nishanth On Fri, Oct 01, 2010 at 07:16:53AM -0500, Peter Ujfalusi wrote: >On Friday 01 October 2010 14:50:37 David Cohen wrote: >> >> > + l = sys_cf = dma_read(OCP_SYSCONFIG); >> >> Shouldn't it be avoided? > >I'm restoring the OCP_SYSCONFIG register later on, and reusing 'l' here to avoid >confusing expression when moving the sDMA to NoStandby. >I could as well introduce other variable for this... > >> >> Regards, >> >> David >> >> > + l &= ~DMA_SYSCONFIG_MIDLEMODE_MASK; >> > + l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE); >> > + dma_write(l , OCP_SYSCONFIG); > >I could have: > dma_write((sys_fc & (~DMA_SYSCONFIG_MIDLEMODE_MASK)) | > DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE), OCP_SYSCONFIG); > >Than I do not need the re-read the CCR, but it looks a bit messy. I think David is concerned about multiple assigments in one line. CodingStyle asks to avoid that. So probably: sys_cf = dma_read(OCP_SYSCONFIG); l = sys_cf; would make chekcpatch.pl --strict happy ?? -- balbi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish 2010-10-01 12:24 ` Felipe Balbi @ 2010-10-01 12:30 ` Peter Ujfalusi 0 siblings, 0 replies; 9+ messages in thread From: Peter Ujfalusi @ 2010-10-01 12:30 UTC (permalink / raw) To: balbi@ti.com Cc: Cohen David (Nokia-MS/Helsinki), Tony Lindgren, linux-omap@vger.kernel.org, Jarkko Nikula, Liam Girdwood, Menon, Nishanth On Friday 01 October 2010 15:24:41 ext Felipe Balbi wrote: > I think David is concerned about multiple assigments in one line. > CodingStyle asks to avoid that. So probably: Yes, I did noticed that after I've sent the reply. > > sys_cf = dma_read(OCP_SYSCONFIG); > l = sys_cf; > > would make chekcpatch.pl --strict happy ?? I'll do that. checkpatch.pl without --strict was happy.. Will resend in a moment. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-10-01 12:43 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-01 11:04 [PATCH v2 0/2] OMAP2/3: DMA: FIFO drain errata fixes Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 1/2] omap: dma: Fix buffering disable bit setting for omap24xx Peter Ujfalusi 2010-10-01 11:04 ` [PATCH v2 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish Peter Ujfalusi 2010-10-01 11:50 ` David Cohen 2010-10-01 12:16 ` Peter Ujfalusi 2010-10-01 12:17 ` David Cohen 2010-10-01 12:43 ` Peter Ujfalusi 2010-10-01 12:24 ` Felipe Balbi 2010-10-01 12:30 ` Peter Ujfalusi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox