Re: ASoC: amd: acp-pdm: full-scale burst on every DMIC capture start

[Mukunda,Vijendar]

On 8/11/26 18:03, Robin Everaars wrote:
> > Could you please try attached patch?
> Thanks. I checked the bound driver before building it and found an error in my
> original report: I named acp-pdm.c, but that is not the path used by this
> machine.
>
> The PX13 is bound as follows:
>
>    /sys/bus/platform/devices/acp_ps_pdm_dma.0/driver/module
>      -> /sys/module/snd_ps_pdm_dma
>
>    snd_ps_pdm_dma:
>      sound/soc/amd/ps/snd-ps-pdm-dma.ko.xz
>      platform alias acp_ps_pdm_dma
>
> The attached patch changes sound/soc/amd/acp/acp-pdm.c, which builds
> snd-acp-pdm. That module is installed but does not own this PCM, so applying the
> patch as-is would not exercise the reported hardware.
>
> The corresponding start sequence is acp63_start_pdm_dma() in
> sound/soc/amd/ps/ps-pdm-dma.c. It also enables the PDM clock, decimator and DMA
> without a settling interval. I can port the 300 ms delay and FIFO flush there
> and test it, but I would prefer to test the exact shape you want upstream. Would
> you send an equivalent patch for snd-ps-pdm-dma,
> or would you like me to prepare
> the test diff?
Will share the patch.
> One detail may also need handling in both versions. PAUSE_PUSH currently takes
> the stop path and disables PDM. After moving PDM_ENABLE to prepare(),
> PAUSE_RELEASE arms only the DMA, and ALSA does not necessarily call prepare()
> between those commands. Should PAUSE_PUSH leave the decimator running, or
> should PAUSE_RELEASE use a separate non-sleeping re-enable path?
>
> Sorry for pointing the original report at the wrong driver. The measurements
> and PCM are unchanged; only my source attribution was wrong.