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

[Andrey Golovko]

On Thu, Aug 13, 2026 at 02:22:52PM +0100, Mark Brown wrote:

> Does this DTRT if userspace restartss the stream by directly calling
> SNDRV_PCM_IOCTL_RESUME (AMD adverise SNDR_PCM_INFO_RESUME...)?

No, it does not.  I wrote a test that takes that path deliberately - it
plays a 440/660 Hz tone straight to the hw device and, when the write
returns -ESTRPIPE, calls snd_pcm_resume() and never snd_pcm_prepare() -
and on this machine, with v1 applied:

                       before suspend     after snd_pcm_resume()
  DP1 PrepareCtrl      0x1 / 0x2          0x0 / 0x0
  PDE23 req / act      0x0 / 0x0          0x3 / 0x3
  tone 440 / 660 Hz    +65.5 / +75.2 dB   -1.7 / +1.8 dB

(two amplifiers on the link, tone measured through the internal
microphone against the noise floor of the same run).  snd_pcm_resume()
returned 0, the PCM stayed RUNNING and nothing logged an error; the
ports were simply never prepared again, so the callback v1 hooks was
never reached.  asoc_sdw_trigger() only calls sdw_enable_stream() on
SNDRV_PCM_TRIGGER_RESUME, and the channels are then enabled on ports
that no longer exist as far as the peripheral is concerned.

v2 preparing the stream on that trigger fixes it:

                       before suspend     after snd_pcm_resume()
  DP1 PrepareCtrl      0x1 / 0x2          0x1 / 0x2
  PDE23 req / act      0x0 / 0x0          0x0 / 0x0
  tone 440 / 660 Hz    +73.7 / +88.3 dB   +73.7 / +88.5 dB

It is on the list as

  [PATCH v2 0/2] ASoC: tas2783: prepare the port again on the resume path
  Message-ID: <20260813194000.10412-1-andrey.golovko@xxxxxxxxx>

> Similarly we can suspend while prepared.

That one I could not close, and I do not think it can be closed from
either the machine driver or the codec.  A stream suspended while merely
PREPARED gets no trigger at all: snd_pcm_do_suspend() returns early when
the stream is not running, and snd_pcm_do_resume() returns early unless
the suspended state was RUNNING or DRAINING.  Userspace calls
snd_pcm_start(), the ports are enabled, and nothing in the path knows
the peripheral came back empty.  sdw_prepare_stream() cannot help
either: the SoundWire stream is still SDW_STREAM_PREPARED, which it
treats as "nothing to do" by design.

What does know is the bus - the peripheral goes UNATTACHED and comes
back uninitialized.  Invalidating the prepared state of the streams that
peripheral takes part in looks like the right place to me.  That is a
core change; tell me if you want it as part of this series and I will
write it.

Vijendar, thanks - that matches what the measurement says, and v2 takes
the first of the two options you named.

Robin, your negative result for v1 earlier today is consistent with all
of this: playback opening cleanly, both amplifiers attached and silent
is exactly what this path looks like from userspace.  Two things worth
checking on your side before you spend another cycle:

  - whether your player recovers with snd_pcm_resume() rather than
    snd_pcm_prepare().  If it does, v1 alone could never have worked for
    you, and v2 is the patch to test;
  - v7.1.7 predates b627da430357 ("ASoC: tas2783-sdw: drop stale
    regcache on uninitialized re-attach"), which is in for-7.3.  Without
    it the register writes made on resume can be dropped by the cache,
    which is a second reason a v7.1.7 test says less than a for-next
    one.

I would take you up on the offer of registers around a failed playback,
but on a for-next kernel with v2 applied.  The register readout above
comes from a small out-of-tree module that reads DPn_PrepareCtrl,
DPn_PrepareStatus, ChannelEn and PDE23 over the bus without touching the
regmap cache; I am happy to send it to you off-list if that helps.

Thanks,
Andrey