On 2020-01-28 18:55, Pierre-Louis Bossart wrote:
On 1/28/20 4:43 AM, Cezary Rojewski wrote:
This set of patches achieves few goals in order to enable data probing feature for audio DSP.
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.
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.
I'd be fine if this was handled in a follow-up series, just want to see if my question is relevant and if yes what it takes to support suspend.
Thanks -Pierre
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.
Czarek