[alsa-devel] [PATCH v3 00/11] ASoC: SOF: Data probing

[Cezary Rojewski]

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@intel.com/
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