On 12/14/20 9:55 PM, Pierre-Louis Bossart wrote:
On 12/14/20 1:28 PM, Daniel Baluta wrote:
Hi Ranjani,
I have few questions about PM flow in SOF.
- Firmware is always loaded at SOF device probe.
Why is that? Is this just an early check that DSP is OK? Because after SND_SOF_SUSPEND_DELAY_MS the SOF device is suspended and DSP is turned off.
It's standard to bring up audio on startup so that you can play a chime and start configuring sound servers.
- What is the correct behavior when immediately after boot
there is a PM suspend/PM resume cycle.
Here is what happens on IMX.
PM suspend -> will do nothing because DSP is already suspended PM resume -> will reload the firmware.
But now the firmware is loaded and DSP is up. And the system stays like this.
Not clear on what you are asking.
If you suspend immediately, i.e. without a couple of ms, despite having configured the device with pm_runtime_use_autosuspend and a generous delay, you are probably missing a pm_runtime_mark_last_busy() on probe/resume to reset counters and prevent an immediate pm_runtime suspend?
How does this looks like on Intel platforms.
We only suspend 4+ seconds after boot or when PulseAudio or other servers are no longer using the device
I am using 2 seconds as suspend delay. So, lets assume system starts then no one is using the SOF device.
So, after 2 seconds the device will enter suspend (runtime suspend because no one is using it).
Then some time later we manually trigger System PM suspend using sysfs interface and setup an RTC
interrupt to wakeup the system later.
(e.g https://developer.toradex.com/knowledge-base/suspend-resume-linux)
So, what should happen now? It looks like the following calls will take place when using OF PM:
=> manually trigger System PM suspend
==> sof_suspend(dev, runtime_suspend=0)
=> (later) wake interrupt from RTC
==> sof_resume(dev, runtime_resume=0)
I