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

[Robin Everaars]

> Could you please re-test with the updated patches, particularly the
> active-capture s2idle resume scenario that originally triggered the BUG?
> The expected result is a clean resume with no scheduling-while-atomic
> warning and successful capture continuation after resume without
> requiring a fresh stream restart.

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

  patch 1  87c2462d4528f13ee14e28df805a7a220b463cf05f59825bdfe4fd70be7cd8a7
  patch 2  6ad1a74b4e276126a2d6d7518b27651aa2d38996e77cffba6f07034d29fc4661
  patch 3  d1af42b8ee371af99cc7056c59cc3feae17cfd69f2f83a89a8ebee47be63e199

The loaded snd_ps_pdm_dma module matched the rebuilt artifact. Its SHA-256
was c2e1a7390584918bab6893943f5231b156e3e9d5db89c307cb9bf7c1e150c63c.

The ordinary paths behaved as follows:

  - The first runtime-suspended capture after boot returned -EIO before
    delivering data and had no matching kernel diagnostic.
 The next five
    runtime-suspended starts each delivered all 48000 frames with no clipped
    or >=99% full-scale samples.
  - 5/5 active warm starts delivered all 48000 frames with 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 recordings delivered 144000 frames with no clipped
    or >=99% full-scale samples.

Active-capture s2idle still fails. I repeated the cycle twice. Both runs
reached ALSA SUSPENDED at the same frame boundary and produced this result:

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

No post-resume sample was delivered in either run. There was no
scheduling-while-atomic warning, BUG, Oops or PDM kernel error, so moving the
sleep out of the trigger callback removed the atomic-context failure. It did
not provide successful capture continuation.

The expected 300 ms settle was also not visible in t
he PM resume interval.
In both kernel traces, the interval from "Suspending console(s)" through the
ACP resume message to "PM: suspend exit" was only about 10 to 12 ms. By
comparison, the same userspace test measured prepare() at 304 ms. This makes
me suspect that acp63_pdm_settle() is not reached from acp63_pdm_resume() for
this active stream, although I have not instrumented the callback to prove
that.

The first fresh open after each resume returned -EIO with no frames, as did
the first cold open after boot. Subsequent fresh captures worked and had no
clipped or >=99% full-scale samples. I am keeping this first-open behavior
separate from the reproducible in-place resume XRUN.

There is also a hardware-coverage gap for patch 3. The patched
snd_soc_ps_mach module was built and installed, but this machine binds
snd_acp_sdw_legacy_mach for its SoundWire card. snd_soc_ps_mach was never
loaded, so I did not exercise the nonatomic link change.

I have withheld Tested-by 
because the active capture fails 2/2 and patch 3
is untested on this machine. I can test another revision or an instrumented
resume callback on the same hardware.

Thanks,
Robin

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

Attachment: signature.asc
Description: OpenPGP digital signature