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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
