[alsa-devel] ASoC: pxa: remove pxa2xx-pcm driver, which caused regression

[Robert Jarzmik]

Petr Cvek <petrcvekcz at 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.

> 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 ?

> 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.

> 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

I'll wait for Daniel to comment on that, he's more advanced in the sound
framework understanding than I am.

Cheers.

-- 
Robert