On Sun, May 11, 2008 at 08:48:30AM +0200, ing. Davide Rizzo wrote:
CCing in Ben, the S3C2410 maintainer (and not snipping any context as a result).
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.
Are you talking about s3c2410_dma_waitforload() here?
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.
Right, and the previous attempt to do so in dma_waitforload() failed. My immediate thought here is that at least for I2S it would probably be very much simpler if the I2S driver were responsible for kicking off the DMA. That seems to be more what the hardware is looking for here.
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.
Hrm. Even for s3c24xx I can't immediately convince myself that this is entirely safe: when I2S is started it does timing sensitive things like synchronise with LRCLK from the codec in slave mode. In general, what's going on here is that devices need to have DMA ready to go before they can start to work on their external bus - without data they may stop entirely or underrun.
Note that platforms are free to ignore any or all of the trigger functions and to have the DAI and DMA drivers cooperate with each other if they need to.
- (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.
Looking at the code it does appear to already be making an effort to ensure that there are multiple buffers queued up with the DMA code in order to avoid underruns: s3c24xx_pcm_enqueue() in s3c24xx-pcm.c will give the DMA code up to the number of buffers in periods_min, which appears to default to 2. I suspect that if the problem with the busy wait is fixed then this will also be fixed.
I wonder if other architectures that use DMA suffer the same problem, so that the 1st proposed solution could help them, too.