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

> Please try attached patches.

I tested the exact two attachments against v7.1.7 on the ASUS ProArt PX13
HN7306EAC. Their SHA-256 values were:

  patch 1  c7e60e6850e3e61582d00a419f20afba863cee8253a3c5afe79a80de9464d8d8
  patch 2  ceda8170c0307415c8d2aabea652b667391801c19a2c34e67eca3216b750f5bd

The ordinary paths remain clean:

  - 5/5 runtime-suspended cold starts and 5/5 warm starts delivered no
    clipped or >=99% full-scale samples.
  - PAUSE_PUSH/PAUSE_RELEASE passed 3/3 with a 0.5 s pause and 3/3 with
    a 2 s pause. All six complete recordings had no clipped or >=99%
    full-scale samples.
  - prepare followed by close passed 3/3, with prepare taking 303 to
    304 ms. Runtime PM suspended the device afterward.
  - forced XRUN/reprepare recovery passed 5/5, with clean recovered
    blocks and prepare times of 304 to 308 ms.

One initial cold attempt returned -EIO before delivering data. It did not
recur in the next five runtime-suspended starts and ther
e was no matching
kernel diagnostic, so I have kept that observation separate from the
reproducible system-resume result below.

Patch 2 cannot sleep in the trigger callback on this path. During a true
active-capture s2idle test, ALSA reached SUSPENDED at frame 90128. On
resume the kernel reported:

  BUG: scheduling while atomic: pdm-alsa-lifecy/13258/0x00000002
  __schedule_bug.cold
  msleep
  acp63_pdm_dai_trigger+0x10d/0x2fc [snd_ps_pdm_dma]
  soc_dai_trigger.part.0 [snd_soc_core]
  snd_soc_pcm_dai_trigger [snd_soc_core]
  soc_pcm_trigger [snd_soc_core]

The comment stating that TRIGGER_RESUME runs in a sleepable PM resume
context does not hold for this ASoC trigger path. snd_pcm_resume() never
returned to the test program, no post-resume sample was delivered and the
program later received SIGSEGV while querying the PCM state in libasound.
The kernel logged a second scheduling-while-atomic warning during core
dump handling.

A fresh capture after resume worke
d and delivered 48000 frames with no
clipped or >=99% full-scale samples.

The settling operation therefore needs a sleepable path before DMA is
armed, rather than msleep() inside the trigger callback. I have withheld
Tested-by and can test another revision 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

wqsEARYIAF0Fgmp9tbAJEB3Ff2vLBhqKNRQAAAAAABwAEHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmcUf7dELrF3wwU4HJUAtdl+FiEEi2uhMrb2XujF
nFjLHcV/a8sGGooAABI7AQDMbQ88mSb9tp0f/F+vD+JWJnJv+KUQ5YpqlGUU
PLXBlwD+JMRNujyq2Vj/PtW5jbK7iEh8CTr+qNsYLFJRbOQLFAM=
=gmcH
-----END PGP SIGNATURE-----