[Sound-open-firmware] Design decisions for PM flow
Hi Ranjani,
I have few questions about PM flow in SOF.
1) 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.
2) 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.
How does this looks like on Intel platforms.
thanks, Daniel.
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
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
On Mon, 2020-12-14 at 19:28 +0000, 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.
Hi Daniel,
The SOF device probe executes a bunch of actions at boot which include probing the DSP, loading and booting the FW followed by registering the machine driver. If we dont load the FW at boot, it would prevent cras/pulseaudio from probing for available PCM devices. And yes, this also helps check if the FW/topology are compatible and fail early if not.
- 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.
How does this looks like on Intel platforms.
On Intel PCI devices, if the device is runtime suspended, it will be brought back tp full power before getting suspended again during system suspend. This is the default expected behaviour for all PCI devices (not just the SOF PCI device). And therefore, system resume will also resume the device before getting runtime suspended again after the suspend delay.
On the IMX, I'd think that if you dont perform any actions during system suspend (because the device was runtime suspended), you shouldnt perform any actions during system resume either. IIRC, you can indicate you want to skip system suspend/resume if the device is runtime suspended by returning 1 during prepare(). Maybe something to try for IMX platforms?
Thanks, Ranjani
On the IMX, I'd think that if you dont perform any actions during system suspend (because the device was runtime suspended), you shouldnt perform any actions during system resume either. IIRC, you can indicate you want to skip system suspend/resume if the device is runtime suspended by returning 1 during prepare(). Maybe something to try for IMX platforms?
the best way to do it is to follow the sequences in pm_runtime.rst (see example in drivers/soundwire/intel.c)
system_suspend(dev)
{
if (pm_runtime_suspended(dev)) {
/* nothing to do */
return 0;
}
}
system_resume(dev)
{
if (pm_runtime_suspended(dev)) {
/* follow required sequence from runtime_pm.rst */ pm_runtime_disable(dev); pm_runtime_set_active(dev); pm_runtime_mark_last_busy(dev); pm_runtime_enable(dev);
}
/* normal resume */
}
Thanks a lot Pierre, Ranjani. I think drivers/soundwire/intel.c is a very good
example and I will use it.
participants (3)
-
Daniel Baluta -
Pierre-Louis Bossart -
Ranjani Sridharan