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

> PAUSE_PUSH should leave the decimator running. That is the safer ALSA
> design and avoids both the transient and a 300 ms pause-resume latency.
>
> Try attached patch.

I tested the exact attachment against v7.1.7 on the ASUS ProArt PX13
HN7306EAC. The bound module was snd_ps_pdm_dma from the rebuilt
sound/soc/amd/ps/ps-pdm-dma.c.

The normal start and pause paths work:

  - 5/5 cold starts, with acp_ps_pdm_dma.0 confirmed runtime-suspended
    before each capture: zero clipped or >=99% full-scale samples in the
    first 300 ms.
  - 5/5 warm starts, with the device confirmed active: the same result.
  - PAUSE_PUSH/PAUSE_RELEASE: 3/3 with a 0.5 s pause and 3/3 with a 2 s
    pause, no ALSA error and no full-scale samples.
  - prepare followed by close without START: 3/3; the device returned to
    runtime-suspended after the 2 s autosuspend delay.
  - forced XRUN/reprepare recovery: 5/5; each recovered block had zero
    clipped or >=99% full-scale samples.

Eac
h prepare took about 304 to 309 ms. A one-second capture took 1.43 to
1.48 seconds wall time, so the expected start latency is visible.

There is a problem on the system-resume path. I kept an ALSA capture
running across one s2idle cycle. The process reached the real ALSA
SUSPENDED state. Immediately after wake:

  SUSPENDED boundary=101384
  RESUME rc=0 (ok) state=RUNNING
  XRUN boundary=101384
  error: Broken pipe

No post-resume sample was delivered. A fresh reopen after resume worked
and contained no clipped samples.

That matches the control flow in the patch: SUSPEND calls
acp63_stop_pdm_dma(), which disables PDM, while RESUME enters
acp63_start_pdm_dma(). That function enables PDM and DMA together when
PDM_ENABLE is clear, without the 300 ms wait or FIFO flush. prepare() is
not called between SUSPEND and RESUME.

Could RESUME use a settling helper before arming DMA, or otherwise force
a prepare/recovery path? I have withheld Tested-by because the in-place

resume test fails. I can test a follow-up patch on the same hardware.

Thanks,
Robin

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: https://gopenpgp.org
Version: GopenPGP 2.10.0

xjMEah8lZRYJKwYBBAHaRw8BAQdAaRkzve49rBEJMKJH746RXHY+2fT77oxROi5d
8JpL+67NKXJvYmluZXZlcmFhcnNAcG0ubWUgPHJvYmluZXZlcmFhcnNAcG0ubWU+
wsARBBMWCgCDBYJqHyVlAwsJBwkQHcV/a8sGGopFFAAAAAAAHAAgc2FsdEBub3Rh
dGlvbnMub3BlbnBncGpzLm9yZx6V5qS89w7CDYSIsc5NxuPJI1rgoEyY/v8dbP3H
qkoNAxUKCAQWAAIBAhkBApsDAh4BFiEEi2uhMrb2XujFnFjLHcV/a8sGGooAAAZs
AP9zIKWwubClFEs0J6jpQHTKXFTq+99MRkfDKqITbumQzQD/R2OazTp4oCJO2bOD
NFliVAm8yXP6A+586zR2YKt0RAbOOARqHyVlEgorBgEEAZdVAQUBAQdA3p5F7b5O
FsWKrSWEmEHia/oe7no/+Z1W0OPffYrDPy8DAQgHwr4EGBYKAHAFgmofJWUJEB3F
f2vLBhqKRRQAAAAAABwAIHNhbHRAbm90YXRpb25zLm9wZW5wZ3Bqcy5vcmevUdR+
V+3UgvIVjqDLFOWyyGp5h4JXAPfYZsD//RHgvQKbDBYhBItroTK29l7oxZxYyx3F
f2vLBhqKAABoFgEA8e4eSLSaLmv8/e2W1L9/VKAbj2Z7JES6KApi9BZ6nQgBANhZ
FhMFzsyzu2YYtaB8SYtVthJJ6/eIQTT6UdQEIYsF
=YKhM
-----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wqsEARYIAF0Fgmp8eCAJEB3Ff2vLBhqKNRQAAAAAABwAEHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmfUHkNIYEWUlttXIb9yKSjsFiEEi2uhMrb2XujF
nFjLHcV/a8sGGooAAJbmAP9XNwDBTB4jcYpMs+N5RzZJruoHe8RRXHVtdzEz
UjS+gwD/TPcyG6yWUVAJ6mpcYBeEL7+iVJt5fwidD0ZQYkzxGQU=
=oPMS
-----END PGP SIGNATURE-----