[Sound-open-firmware] Design decisions for PM flow
Ranjani Sridharan
ranjani.sridharan at linux.intel.com
Mon Dec 14 22:54:44 CET 2020
On Mon, 2020-12-14 at 19:28 +0000, Daniel Baluta wrote:
> 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.
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.
>
> 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.
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
More information about the Sound-open-firmware
mailing list