forked from Minki/linux
c12abc012e
Simultaneous audio playback and capture on OMAP1510 can cause that second stream is stalled if there is enough delay between startup of the audio streams. Current implementation of the omap_mcbsp_start is starting both transmitter and receiver at the same time and it is called only for firstly started audio stream from the OMAP McBSP based ASoC DAI driver. Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is missed if there is no DMA transfer set up at that time when the first word after McBSP startup is transmitted. The problem hasn't noted before since later OMAPs are using level sensitive DMA request lines. Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by allowing to start and stop individually McBSP transmitter and receiver logics. Then call those functions individually for both audio playback and capture streams. This ensures that DMA transfer is setup before transmitter or receiver is started. Thanks to Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> for detailed problem analysis and Peter Ujfalusi <peter.ujfalusi@nokia.com> for info about DMA request line behavior differences between the OMAP generations. Reported-and-tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> |
||
---|---|---|
.. | ||
include/mach | ||
clock.c | ||
common.c | ||
cpu-omap.c | ||
debug-devices.c | ||
debug-leds.c | ||
devices.c | ||
dma.c | ||
dmtimer.c | ||
fb.c | ||
gpio.c | ||
i2c.c | ||
io.c | ||
iommu.c | ||
iopgtable.h | ||
iovmm.c | ||
Kconfig | ||
mailbox.c | ||
Makefile | ||
mcbsp.c | ||
mux.c | ||
ocpi.c | ||
sram.c | ||
usb.c |