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

[Robin Everaars]

> 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

Attachment: publickey - robineveraars@pm.me - 0x8B6BA132.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature