On 2020-01-28 22:11, Pierre-Louis Bossart wrote:
I am fine with this update, but I just thought of an obscure case and couldn't find the answer on my own.
These probe points are enabled/disabled with direct IPC calls. Once those routines have been called, I don't see any context maintained by the driver (other than the stream tag for the extractor).
These do not need to be maintained by the driver at all, it's FW's job actually. Notice the existence of _INFO getters for probe_points and dmas. FW caches all the necessary info for us and when required, host can request for it via IPCs.
D'oh. That's a major disconnect I am afraid.
When the the PCI device enters D3 on APL+, the power rails are turned off and the SOF firmware does not save any context. On D0 resume, the power rails are turned back on, firmware is downloaded again, and ALSA/ASoC/topology cores restore the context with a set of IPCs.
The behavior you describe might be relevant for previous versions of the closed-source firmware but not for SOF as of today. The firmware-initiated context save/restore just does not exist.
I also wonder if a firmware-only solution would work, the DMA stream tags are allocated on the host side, so on resume you could have a coherency issue with possibly mismatches.
Driver makes use of such operation during sof_probe_compr_free(). Before _probe_deinit() is called, all the probe_points should be disconnected and all the dmas detached. Since this patchset addresses extraction-only (from the runtime point of view), the later is ignored.
So here's my question: what happens if there is a pm_runtime or system suspend after playing with debugfs to configure those probes? Would all context be lost and the user needs to re-enable all probes?
Also what happens if there is a system suspend while an extractor is opened, would it be restored? I imagine a pm_runtime suspend is not possible since the device is active then.
As stated, there is no cache on the host side, caching is left up to FW alone. Debugfs files act only as a ipc-proxies. As probes require device to be up and running, suspend is not possible. After suspend, I believe FW context would be lost so all the actions had to be repeated.
I'd suggest consulting SOF FW team in regard to probes design if you want to pursue the suspend case - whether it is achievable or not.
That team is in your building :-)
suspend/resume support is a requirement for all SOF capabilities - no exceptions. At minimum, you would want to do a pm_runtime_get_sync() to prevent runtime_pm from kicking-in while probes are enabled.
To make it clear: probes are not supported during D3/ S3.
Now to be transparent with the rest of the readers: change keeping the device alive throughout the entire lifetime of extractor compress stream has been merged on 2019-12-17: https://lore.kernel.org/alsa-devel/20191217095851.19629-7-cezary.rojewski@in... so we're sure the suspend scenario will never occur.
However, indeed we could be more verbose - so user is not confused why his actions executed on probe-debugfs files are failing. To address this, v4 debugfs handlers output additional messages when invoked with no extraction stream running.
Czarek