ASoC: pxa: possible regressions

[petrcvekcz@gmail.com (Petr Cvek)]

Dne 13.8.2018 v 07:54 Daniel Mack napsal(a):
> Hi Petr,
> 
> On Wednesday, August 08, 2018 11:07 AM, Petr Cvek wrote:
>> Dne 8.8.2018 v 07:38 Daniel Mack napsal(a):
> 
>> I was planning to send patches before I've found regressions in the
>> current -next.
>>
>> I think I've had the first working version somewhere around 3.13, but I
>> was updating versions only sporadically and fixing audio had low
>> priority (higher priority got iwmmxt compiler, platform init source
>> code, charger, USB, MMC and IrDA). Some versions until now worked, some
>> didn't.
>>
>> The last version I've used and where the sound worked was
>> 4.14.0-rc7-next from somewhere around 3rd November 2017. The patch for
>> sound subsystem should be the same as the current one.
> 
> That's strange, because as I said, the SSP rework went in in 4.0, so
> without my regression fix (737e370a57e4e8 "ASoC: pxa-ssp: allow more
> flexible setup order"), I doubt SSP had worked for you.
> 

OK I found the problem I've had compiled and load (on both v4.14 and
v4.18) snd-soc-pxa2xx driver (from linux/sound/arm/pxa2xx-pcm.c). This
component calls pxa2xx_soc_pcm_new() which is already called by
snd_soc_pxa_ssp (pxa-ssp-dai.0) or snd_soc_pxa2xx_i2s (pxa2xx-i2s). In
the function the dma gets registered twice, which is a wrong behavior
(kernel oops on DMA stopping). Without snd-soc-pxa2xx driver loaded the
playback works (after the rest of my patches) so it seems in the old
version DMA wasn't registered twice.

So the easy solution for snd_soc_pxa_ssp OR snd_soc_pxa2xx_i2s would be
a mutual exclusivity with snd_soc_pxa_ssp. I don't know about other
users, but I can add a condition to magician Kconfig entry.

Best regards,
Petr