On 11/08/2011 12:39 PM, Mark Brown wrote:
On Mon, Nov 07, 2011 at 09:19:07PM +0100, Clemens Ladisch wrote:
Daniel Mack wrote:
I guess this is some sort of a race condition in the stream startup, and suspected sound/soc/pxa/pxa-ssp.c to lack some locking, so I added a spinlock around all register read-modify-write cycles. But that doesn't seem to be the reason.
I'd guess this is a race in the programming of the L/R clock signals; try putting a lock/mutex about all the stream initialization code, and maybe adding some delay.
That's very unlikely to help, these issues are generally issues with the controller not being able to figure out which clock edge to start on properly and if there are problems here locking is unlikely to help - the issue is the two hardware blocks synchronizing with each other, usually with the clocks driven from an asynchronous domain.
Unfortunately, yes. We're currently trying to do some more investigation of the exact effects, see if we have swapped channels on both streams (which the "aplay | arecord" wouldn't unveil) etc.
Still, I wonder whether locking wouldn't be important in sound/soc/pxa/pxa-ssp.c, as all the per-substream functions actually operate on the registers of the ssp port that is shared between capture and playback. And the code does things like
u32 sscr0 = pxa_ssp_read_reg(ssp, SSCR0); if (cpu_is_pxa25x() && ssp->type == PXA25x_SSP) { sscr0 &= ~0x0000ff00; sscr0 |= ((div - 2)/2) << 8; /* 2..512 */ } else { sscr0 &= ~0x000fff00; sscr0 |= (div - 1) << 8; /* 1..4096 */ } pxa_ssp_write_reg(ssp, SSCR0, sscr0);
all over the place. I'm just curious whether there there is anything in the ASoC core that cares for this?
Thanks, Daniel