Re: [PATCH] ASoC: tas2783-sdw: power the Function up before preparing the port

I tested the exact inline patch from this message against v7.1.7 on the ASUS
ProArt PX13 HN7306EAC. The normalized patch SHA-256 was:

  68e9ae1300b17a7ba129b38c89d650964a8049cb03797a5eaf762f2d3fa78b40

The bound snd_soc_tas2783_sdw module had SHA-256:

  ec9eef4eb83f81761127c39c5da13d4ddb741f111fe2dcb6b64a5c4e0db245c0

I disabled and masked my resume rebind service before the test. The separate
boot rebind stayed enabled because this machine still hits the unrelated
32 KiB firmware-write timeout during cold boot; it recovered both amplifiers
on its first attempt before the baseline measurement.

Before suspend, a controlled 2 kHz both-channel tone measured +58.7 dB over
baseline through the internal microphone:

  baseline combined       2.2
  tone combined        1799.4

The machine then completed an s2idle cycle from 16:41:19 to 17:13:44, about
32 minutes 25 seconds. The resume rebind remained masked and had no journal
entries.

After resume, playback opened 
and ran without a TAS2783 error and both amps
remained Attached and bound to slave-tas2783, but the speakers were silent. A
valid repeated acoustic capture measured:

  baseline combined       0.6
  tone combined           0.2
  tone relative to baseline  -10.8 dB

The first post-resume microphone capture produced an empty WAV due to the
separate first-open issue already reported in the ACP PDM thread. I discarded
that measurement, confirmed the DMIC could capture directly, then repeated the
speaker measurement above with 353280 captured frames.

So the PRE_PREP power-up patch does not fix the post-S0i3 speaker silence on
this board. I am withholding Tested-by. The result suggests that restoring
PDE23 is necessary for port preparation but is not sufficient for this
machine's full TAS2783 resume state.

One unrelated event occurred during the same resume: the RT721 jack-detect
worker hit a NULL dereference in snd_jack_report(). Its stack did not contain
TAS2783 or So
undWire port preparation, so I have not attributed the speaker
result to that Oops.

I can test a follow-up patch or collect specific TAS2783 registers around the
failed playback if useful.

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

wqsEARYIAF0Fgmp94SQJEB3Ff2vLBhqKNRQAAAAAABwAEHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdWWi0wsVZeVYs7Sa1LngrxFiEEi2uhMrb2XujF
nFjLHcV/a8sGGooAAI4cAQDuZMLZdPqitEYjCl60TjpY5zfGejbe9uksn3SR
qy6tAAEA1Vt87ZbY8F3GDa+kSidfD9ZR2rYCYrPkK/q3k5T3hgk=
=nk6t
-----END PGP SIGNATURE-----