Dne 29.8.2018 v 16:11 Robert Jarzmik napsal(a):
Petr Cvek petrcvekcz@gmail.com writes:
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() .
Mmh no, at least no if you're speaking of sound/soc/pxa/pxa2xx-ac97.c.
I placed a printk in snd_pcm_new(), and it is called 2 times from mioa701_wm9713.c, to register the wm9713-hifi and wm9713-aux devices.
Now if you speak of sound/arm/pxa2xx-ac97.c, it should never be selected in an "soc" variant, whenre sound/soc/pxa/pxa2xx-ac97.c should be used.
Mea culpa I _did_ read sound/arm/pxa2xx-ac97.c. That means I still don't know why pxa2xx_soc_pcm_new() is fine on the AC97.
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.
Ok, I suppose you have checked this with a printk, WARN_ON() be sure, right ? And could you send me you .config, just to be sure we're on the same page on the drivers you're using.
If that's the case, Daniel would you have a look into it please ?
I've put printks in almost every sound function by now ;-). It gets called in soc_new_pcm() from for_each_rtdcom iterator. For SSP the the function is defined in pxa_ssp_component, for I2S it is defined in pxa_i2s_component and for sound/soc/pxa/pxa2xx-pcm.c there is the definition in pxa2xx_soc_platform.
BTW sound/soc/pxa/pxa2xx-ac97.c have the definition in pxa_ac97_component struct.
Could you place printks in soc_new_pcm() around code from link?
https://elixir.bootlin.com/linux/v4.19-rc1/source/sound/soc/soc-pcm.c#L3155
for_each_rtdcom(rtd, rtdcom) { component = rtdcom->component;
pr_info("TEST component: %p %s\n", component, component->name);
if (!component->driver->pcm_new) continue;
ret = component->driver->pcm_new(rtd);
pr_info("actually called=%i\n", ret);
if (ret < 0) { dev_err(component->dev, "ASoC: pcm constructor failed: %d\n", ret); return ret; } }
I got this log:
magician-audio magician-audio: ASoC: registered pcm #0 UDA1380 Playback uda1380-hifi-playback-0 TEST component: 95cf8217 pxa-ssp-dai.0 ... (pxa2xx_soc_pcm_new gets called for pxa-ssp-dai.0) actually called=0 TEST component: 47284e1d uda1380-codec.0-0018 TEST component: 1e982c1f pxa-pcm-audio ... (pxa2xx_soc_pcm_new gets called for pxa-pcm-audio) actually called=0 magician-audio magician-audio: uda1380-hifi-playback <-> pxa-ssp-dai.0 mapping ok magician-audio magician-audio: ASoC: probe Magician dai link 1 late 2 magician-audio magician-audio: ASoC: registered pcm #1 UDA1380 Capture uda1380-hifi-capture-1 TEST component: 30bbb218 pxa2xx-i2s ... (pxa2xx_soc_pcm_new gets called for pxa2xx-i2s) actually called=0 TEST component: 47284e1d uda1380-codec.0-0018 TEST component: 1e982c1f pxa-pcm-audio ... (pxa2xx_soc_pcm_new gets called for pxa-pcm-audio) actually called=0
Config attached, only differences from vanilla should be ov9640 camera and reverted IrDA removal.
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.
Very true. I hope you're using CONFIG_PXA_DMA=1 and not CONFIG_MMP_PDMA, this will enable us to debug when things will get out of control.
I do from the beginning. Is it even possible to use CONFIG_MMP_PDMA on PXA27x?
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.
At least we must find a way to have :
- pxa2xx_pcm_open() called only once
- pxa-pcm-audio shoud be used for SSP based PXA boards
It may be possible to remove the block bellow from SSP and I2S drivers but it will change the situation for every platform which uses SSP or I2S:
.ops = &pxa2xx_pcm_ops, .pcm_new = pxa2xx_soc_pcm_new, .pcm_free = pxa2xx_pcm_free_dma_buffers,
The generic functions would be then called just from pxa-pcm-audio component.
Petr