On Mon, 29 Jun 2009 09:37:58 +0300 Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
Hmmm, I had taken a look at the 2.4.21 kernel sources, which I have laying around in my disk from an old project which used OMAP1510. The OSS audio code does use the CPC register for determining the DMA progress both for playback and recording. I know that the audio was working OK on that board, since we had doom running there. The difference that I can see is that the OSS code also configured the CCR:SYNC(4:0) bits as well. Looking at the DMA_CPC register description in the OMAP1510 TRM: it list two cases on how it behaves and both require the DMA_CCR:SYNC != 0...
The current DMA code for OMAP1510 just plain ignores the DMA_CCR:SYNC for some reason. Can you try the following patch:
iff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 7fc8c04..38874e4 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count, ccr &= ~(1 << 5); if (sync_mode == OMAP_DMA_SYNC_FRAME) ccr |= 1 << 5;
if (dma_trigger)ccr |= dma_trigger & 0x1f; dma_write(ccr, CCR(lch)); ccr = dma_read(CCR2(lch));Than can you print out in case of playback both the destination and source addresses supplied to the DMA, than in the pointer callback also print out the value returned by the omap_get_dma_src_pos function to see if this actually helps?
Thanks for info Peter. So, Mark, put the workaround patch and my acked-by on hold until this is also tried.