Re: ASoC: tas2783-sdw: port prepare never completes after S0i3, no audio and no error (AMD ACP7.0, ASUS ProArt PX13)

[Andrey Golovko <andrey.golovko@gmail.com>]

Answering my own question from a few hours ago, since I said I would
report back on option (a) and the answer turned out to be more definite
than I expected: (a) cannot work, and (b) is enough on its own.

A patch is posted here:

  https://lore.kernel.org/all/20260813001500.9218-1-andrey.golovko@gmail.com/

(a) does not work, and not by a small margin
============================================

I built a kernel with SNDRV_PCM_INFO_RESUME dropped from the SoundWire
DMA PCMs and nothing else changed. Still silent after resume. The
register state says why:

  DPn_PrepareStatus  0x1 / 0x2      still not prepared
  ChannelEn          now in bank 1  so the stream really was re-prepared
  PDE23              req=0x3 act=0x3

So dropping the flag did make userspace stop trying to resume the stream
in place: the port was prepared afresh, the bank flipped, PrepareCtrl was
written. It just did not help, because after resume userspace calls
snd_pcm_prepare(), which reaches .prepare and sdw_prepare_stream() and
never hw_params() again -- ALSA only requires hw_params() after
hw_free(). The Function power-up lives in tas_sdw_hw_params(), so it is
skipped on every recovery path, flag or no flag.

That is worth stating plainly because it kills a whole family of fixes:
no PCM capability flag and no change of userspace behaviour can put the
power-up back, as long as it sits on a callback that recovery does not
re-run.

(b) is enough
=============

The patch powers PDE23 up in tas_port_prep(), in the PRE_PREP case,
immediately before the PrepareCtrl write that function already does. The
dependency is thereby satisfied on every path that prepares a port,
which is what the hardware actually requires.

No ACP change is involved: the tested kernel does not carry the
INFO_RESUME patch. Same machine, s2idle for 8 min 51 s with 526 s of S0i3
residency, px13-audio-restore workaround service disabled:

  PDE23 req=0x0 act=0x0   DPn_PrepareStatus 0x0 / 0x0   audio after
  resume, with no user intervention at all

Two remarks
===========

Niranjan, Shenghao -- the hw_free() path still writes PS3, and with this
patch the power-up now happens in port prepare while the power-down stays
in hw_free(). That asymmetry works, but if you would rather have the
power-down move to the POST_DEPREP case for symmetry, say so and I will
respin. I left it alone because hw_free() is also the point where the
stream is removed from the slave, and I did not want to change the
power-down timing while fixing the power-up.

Pierre-Louis, my question about simple_ch_prep_sm from the previous mail
stands, and this result sharpens it: the failure was silent for months
only because the core skips the NOT_PREPARED poll for this codec. Had it
polled, sdw_prep_deprep_slave_port() would have printed "Chn prep failed
for port 1" on the first resume. Whatever happens to this patch, TI may
want to reconsider that property.

Thanks,
Andrey