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