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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
