[alsa-devel] ARM S3C2410: Trigger start problems
ing. Davide Rizzo
davide at elpa.it
Sun May 11 08:48:30 CEST 2008
I experienced a curious problem.
My platform is a S3C2410 with a PCM3006 codec connected through I2S.
The soc trigger function calls 3 other triggers functions:
- first the codec function
- then the platform function (that starts dma)
- last the the i2s trigger function (that starts i2s peripheral).
The dma start function programs and starts the dma peripheral, but the
transfer doesn't start because the i2s peripheral isn't started yet.
The s3c2410 specific dma start programs the 1st transfer, but before
programming the 2nd start it waits about 30ms (2^18 count) in a closed
loop for 1st transfer to start. After that delay anyway it fails to
program the 2nd transfer.
After that, when the i2s trigger function is called the 1st samples'
group starts, but nobody preprograms the 2nd sample group in the dma
peripheral. When the 1st group ends the dma interrupt service routine is
called , but it's too late and the 1st samples' group is repeated twice.
I tested 2 solutions:
- In the soc trigger function, call the i2s trigger function BEFORE the
platform trigger function. I don't know if this solution could broke
other platforms, but it's the more correct way to solve the problem.
- (platform specific): In arch/arm/plat-s3c24xx-dma.c, at the end of
s3c2410_dma_getposition() function, insert a call to
s3c2410_dma_started(). That function is periodically called by alsa-lib
when playing, and permits dma to program the 2nd buffer before (but it's
not guaranteed) the 1st group is completed. With this solution, the
programming of DMA till waits for the closed loop. I think this is a
patch, but not the correct solution.
I wonder if other architectures that use DMA suffer the same problem, so
that the 1st proposed solution could help them, too.
More information about the Alsa-devel