On Mon, 29 Jun 2009 09:37:58 +0300 Peter Ujfalusi <peter.ujfalusi@xxxxxxxxx> 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. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html