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

Robin Everaars <[email protected]>
Newsgroups gmane.linux.sound,gmane.linux.kernel
Message-ID <[email protected]>
> 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
publickey - [email protected] - 0x8B6BA132.asc (application/pgp-keys, 889 B)
-----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-----
signature.asc (application/pgp-signature, 322 B)
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wqsEARYIAF0FgmqMS10JEB3Ff2vLBhqKNRQAAAAAABwAEHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdKIgitka2ZAKcW2XCCml/XFiEEi2uhMrb2XujF
nFjLHcV/a8sGGooAAIS5AQCxnV9KdYuZ/QQf6SA/5ripU6jChs04+5z4bEmQ
v3aEGgEAy9LM8dkgc8AdRMDQoRXM9KCjtzNnkcOayfJFyznkjws=
=/Dhg
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.