lkml.org 
[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [PATCH] [RFC] ASoC: OMAP: fix OMAP1510 broken PCM pointer callback
Date
On Monday 29 June 2009 01:08:59 ext Janusz Krzysztofik wrote:
>
> AFAIK, both CSSA_L and CDSA_L DMA registers are static. Loaded by CPU with
> 16 LSB of initial source and destination port addresses respectively, they
> are never updated by the DMA engine itself. That's why they can't be used
> for transfer progress indication unless updated by CPU.
>
> The old omap-alsa driver was just updating them, intentionally or not, by
> reprogramming and restarting DMA every PCM period. That's why calculating
> PCM pointers from CSSA_L/CDSA_L worked.
>
> ASoC OMAP driver transfers whole PCM buffer with single DMA transfer, so it
> doesn't need to update DMA source/destination port address after initial
> playback/capture setup, even if restarting DMA, and actually never does
> this. Calculating PCM pointers from CSSA_L/CDSA_L registers without
> updating them every period would then be wrong.
>
> For capture, reading CPC, that follows destination port address progress,
> just works fine (for both old and new driver). For playback, similar
> hardware functionality seems to be missing, so it has to be emulated in
> software if required.

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?

--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-06-29 08:41    [W:0.057 / U:8.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site