Re: [alsa-devel] [PATCH v3 00/11] ASoC: SOF: Data probing - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org, tiwai@suse.com,
	lgirdwood@gmail.com
Subject: Re: [alsa-devel] [PATCH v3 00/11] ASoC: SOF: Data probing
Date: Tue, 28 Jan 2020 15:11:38 -0600	[thread overview]
Message-ID: <450d7f9a-239a-0251-a58f-60591cc92736@linux.intel.com> (raw)
In-Reply-To: <462e700e-96e8-8941-5de1-fd8ef5f6c18f@intel.com>

>> 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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel