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

[Robin Everaars]

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

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

Attachment: signature.asc
Description: OpenPGP digital signature