[alsa-devel] Swapped channels issue on pxa-ssp based platforms

[Daniel Mack]

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