summaryrefslogtreecommitdiffstats
path: root/arch/arm/configs/pxa168_defconfig
diff options
context:
space:
mode:
authorJarkko Nikula <jhnikula@gmail.com>2010-10-11 14:18:45 -0700
committerTony Lindgren <tony@atomide.com>2010-10-11 14:18:45 -0700
commit3e57f1626b5febe5cc99aa6870377deef3ae03cc (patch)
tree19a93b368344ebf64fd7d57b01133e9f28dd54b2 /arch/arm/configs/pxa168_defconfig
parenta1b04cc197e17c47b043051becb548dc8c60c886 (diff)
downloadblackbird-op-linux-3e57f1626b5febe5cc99aa6870377deef3ae03cc.tar.gz
blackbird-op-linux-3e57f1626b5febe5cc99aa6870377deef3ae03cc.zip
omap: dma: Fix buffering disable bit setting for omap24xx
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> Acked-by: Manjunath Kondaiah G <manjugk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Diffstat (limited to 'arch/arm/configs/pxa168_defconfig')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud