Dne 25.8.2018 v 10:39 Robert Jarzmik napsal(a):
Petr Cvek petrcvekcz@gmail.com writes:
Dne 18.8.2018 v 21:10 Robert Jarzmik napsal(a):
Petr Cvek petrcvekcz@gmail.com writes:
My bad I've forgot to add "select SND_PXA2XX_LIB" from removed SND_PXA2XX_SOC, now it should compile, can you test it if it works now? fixed patch in [1].
Still NAK.
You must realise that as long as you will delete sound/soc/pxa/pxa2xx-pcm.c, I'll block the patch, as it is being used for music playback on several pxa platforms, at least the AC97 based ones.
I know I will send the magician only patch. I've just wanted to know how it is working with AC97 ;-) (+ it is still a good test for possible future changes).
BTW can you try insmod-aplay-stop-rmmod with the current -next on your board?
Ok, I just did that. I based my work on linux-next, plus one extra patch which was lost in my last submissions : https://groups.google.com/forum/#!topic/linux.kernel/0iw-VDxIyZk
I insmoded the modules, called aplay, heard the music, rmmoded all the modules, then insmoded again, called aplay, and rmmoded again. Everything worked smoothly.
Hi guys,
...the continuation of a sound fix for (not only) HTC magician
I think I got it now. It seems mioa701_wm9713 calls snd_pcm_new() twice (once in pxa2xx-ac97.c and once in mioa701_wm9713.c by devm_snd_soc_register_card() . This doesn't cause a double DMA allocation (as both will be for the different "card"). Still you should have allocated unused DMA resources somewhere on mioa by pxa2xx_soc_pcm_new() from pxa2xx-pcm.c (= dead code).
Problem on non AC97 boards is as follows:
As defined in machine's struct snd_soc_dai_link the individual components' .pcm_new() gets called. The first will be the component .cpu_dai_name="pxa-ssp-dai.0" and by definition in pxa-ssp.c this calls pxa2xx_soc_pcm_new() which allocates DMA.
The problem is when the second component's .pcm_new() is called by the definition .platform_name = "pxa-pcm-audio" which calls again pxa2xx_soc_pcm_new() which allocates the DMA for the second time.
This problem should be same for the most of the PXA boards, which are using SSP.
A trivial comment-out of .platform_name works sometimes works, as drivers without .platform_name record gets supplied by snd-soc-dummy. And this solution has yet another problem.
The PXA27x DMA controller doesn't support a full 8192 bytes per transmission (limited by .period_bytes_max), but only up to 8191 bytes (o_O), so any DMA buffer request must be in multiples of like 8160 bytes (or less, 8160 itself must be in the multiples of 32). This hw constraint gets set by calling pxa2xx_pcm_open(). The problem is snd-soc-dummy registers its own dummy_dma_open() and indeed it gets called after pxa2xx_pcm_open() and rewrites the values by its own dummy data. (Un)luckily the value gets overwritten to 8192 bytes and DMA allocation fails.
Can somebody give me suggestions how to fix this? Changing the .period_bytes_max value in snd-soc-dummy works, deleting dummy_dma_open() works, changing pxa2xx_soc_platform_probe() to just return works too (that's why I've decided pxa2xx-pcm.c could be removed). But all these changes are ugly and not usable.
Thanks for help.
best regards, Petr