Re: ASoC: tas2783-sdw: calibration firmware not re-downloaded after s2idle resume (AMD ACP SoundWire, ASUS ProArt PX13)

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

Thanks for the quick response.

> restoring the dma ring buffer reigsters, pte programming along with
> re-enabling irq mask will be done in acp70_restore_sdw_dma_config()
> function which will be invoked during resume sequence.

You are right, and my earlier description of that part was wrong - I
apologise. acp63_sdw_pcm_resume() is the SYSTEM_SLEEP resume callback and
it does exactly that for every live substream, and it has been there
since v7.2-rc1. My claim that the ring buffer registers are only
programmed in hw_params was incorrect.

I have since measured it on the hardware instead of reading code, and the
measurements confirm your point: the ACP side is fine, and the audio is
lost somewhere else entirely.

Setup: ASUS ProArt PX13 HN7306EAC, ACP rev 0x70, two TAS2783 + RT721 on
link 1, v7.2-rc4 plus 5893013efabb. One s2idle cycle of 147 s with 140 s
of S0i3 residency, i.e. a real power gate. After resume the speakers are
silent, with no error anywhere in the log.

1) ACP registers during silent playback versus during working playback
(after the card profile is cycled, which restores audio): I dumped ring
buffer address/size, FIFO address/size, DMA size, watermark, stream
enable and the SoundWire manager block - 72 of 78 registers are
bit-identical. The only differences are ACP_EXTERNAL_INTR_CNTL, where the
silent capture has the extra PDM_DMA_INTR_MASK bit because the mics
happened to be open, and the last immediate command/response pair. So
acp70_restore_sdw_dma_config() does its job.

2) The DMA is running while silent. Sampling
ACP_P1_AUDIO1_TX_LINEARPOSITIONCNTR every 500 ms:

  +96064, +96000, +96064, +96064, +96000 bytes

96000 bytes per 500 ms = 192000 B/s = 48 kHz x 2 ch x 2 bytes, exactly
nominal. The ACP fetches the buffer and feeds the SoundWire FIFO for the
entire time the speakers produce nothing.

3) The difference is on the peripherals. Dumping
/sys/kernel/debug/soundwire/master-0-1/sdw:*/registers during playback,
silent versus working, the whole difference across all three peripherals
is one register, on both amplifiers:

  DP1 0x104 (DPn_PrepareStatus):  silent = 0x3   working = 0x0

with DPn_PrepareCtrl = 0x3 and DPn_ChannelEn = 0x3 in both cases. Since a
set bit there means "not prepared" (the core polls for NOT_PREPARED == 0
in sdw_prep_deprep_slave_ports()), both amps sit with their port
unprepared while the manager streams at them. Nothing notices, because
tas2783-sdw declares simple_ch_prep_sm, so the core skips its
write-and-poll and the codec's own tas_port_prep() writes
DPn_PrepareCtrl without ever checking the status.

I have sent the details of that part to the TI folks in a separate thread
so as not to derail this one.

I will file a Bugzilla ticket with the full dmesg (dyndbg enabled), the
register dumps from both states and the DMA counter trace, and post the
number here.

One question while I have your attention: given that
acp70_restore_sdw_dma_config() restores the DMA configuration on resume,
is SNDRV_PCM_INFO_RESUME on the SoundWire DMA PCM intended? Intel does
not set it for SoundWire, and with it userspace can issue TRIGGER_RESUME
and skip prepare entirely. On this board that path leads to the silent
state described above, though after these measurements I no longer think
the flag is the root cause.

Thanks,
Andrey