[Sound-open-firmware] About sof and D0 D3 states, 'standby' and 'suspend to RAM'

[josep lladonosa capell]

hank you, Paul, Pierre.


Missatge de Pierre-Louis Bossart
<pierre-louis.bossart at linux.intel.com> del dia dj., 23 d’abr. 2020 a
les 22:39:
>
> Hi Josep,
>
> > I have found[1]  that sof driver works (for now?) only two power
> > states: D0 (DSP ON) and D3 (DSP OFF).
> > In a laptop with battery, not connected to AC, I have many
> > "D0->D3->D0" state changes during system operation [3].When entering
> > into to D0, all firmware is loaded again, DSP set up and so (obvious,
> > as DSPs where off).
> >
> > My guess is that this transition happens in a power state transition
> > lower than Suspend to RAM, i.e., Suspend-to-idle or Standby. [2]
> >
> > Should not be the transition to D3 state done in a kernel transition
> > to S3 or higher only (Suspend to RAM, hibernate)?
>
> Adding to Paul Olaru's answer: it's a feature not a bug ;-)
>
> There are two types of suspend/resume operations, tied to transitions
> between S (platform) and D (device) states.
>
> a) system suspend/resume, where the platform goes to a different S
> state. On system suspend, the platform goes e.g. to S3 to hibernate, and
> that forces the device state to go to D3 - platform and device states
> are not completely independent.

Let me point that hibernation is the S4 state (perhaps you meant going
to S3 before entering S4).
TIL that there is a pm-suspend-hybrid where system enters S3 but all
stuff related to hibernation is done, just in case of a power outage.

>
> b) pm_runtime suspend/resume. Here the platform remains in S0 (active)
> but since when the audio subsystem is not used, the pm_runtime framework
> will trigger a transition to D3, typically after a timeout. Conversely
> every time you want to play/record the ALSA/ASoC framework will do a
> pm_runtime_get_sync() and force the DSP to be powered, initialized, etc.
>
Yes, this is what is happening on this machine.
But having the kernel debug on, there were lots of lines generated.
Now, with debug off, there are less lines but all returns from
suspensions reflected (dmesg, filtered output):

[ 1234.873521] sof-audio-pci 0000:00:1f.3: error: no reply expected,
received 0x0
[ 1234.987970] sof-audio-pci 0000:00:1f.3: firmware boot complete
[ 1265.505793] sof-audio-pci 0000:00:1f.3: error: no reply expected,
received 0x0
[ 1265.610384] sof-audio-pci 0000:00:1f.3: firmware boot complete
[ 1299.705790] sof-audio-pci 0000:00:1f.3: error: no reply expected,
received 0x0
[ 1299.807626] sof-audio-pci 0000:00:1f.3: firmware boot complete
[ 1336.834937] sof-audio-pci 0000:00:1f.3: error: no reply expected,
received 0x0
[ 1336.945493] sof-audio-pci 0000:00:1f.3: firmware boot complete
[ 1346.829315] sof-audio-pci 0000:00:1f.3: error: no reply expected,
received 0x0
[ 1346.925273] sof-audio-pci 0000:00:1f.3: firmware boot complete

(error lines are because DSP replies with a 0x0 and it was not
expected - maybe this case could be filtered...)

Maybe it is related to pm, as you said.
I found that TLP application (the one in my Debian) allows specific
powersave configuration for sound but what it does is related to

/sys/module/snd_hda_intel/parameters/power_save
/sys/module/snd_hda_intel/parameters/power_save_controller

module load parameters. First is in seconds (can be 0) and second is
Y/N  but as you can see they are related to snd-hda-intel, not with
sof.

For the moment I see that I will have to deal with it as it is now,
with so close firmware reloads (in 3, 6, 11 seconds), following
directly the PM state change without a specific sof sound timeout.
Lines from /var/log/kern.log (filtered):

Apr 24 08:03:19 debian kernel: sof-audio-pci 0000:00:1f.3: firmware
boot complete
Apr 24 08:03:40 debian kernel: sof-audio-pci 0000:00:1f.3: firmware
boot complete
Apr 24 08:03:46 debian kernel: sof-audio-pci 0000:00:1f.3: firmware
boot complete
Apr 24 08:03:49 debian kernel: sof-audio-pci 0000:00:1f.3: firmware
boot complete
Apr 24 08:04:00 debian kernel: sof-audio-pci 0000:00:1f.3: firmware
boot complete

Thanks,
Josep

> Not all platforms have the same power management capabilities. On Intel
> recent hardware, the DSP is power-gated so all state is lost. That's why
> we have to re-download it on each D0 transition. If you look at older
> hardware, we didn't have power gating, only clock gating so
> re-downloading the firmware was not necessarily needed for pm_runtime,
> and only needed on system resume.
>
> If you look at sound/soc/sof/pm.c you will see we have two hooks for
> each type of suspend/resume, and calls into the platform specific parts
> for the implementation.
>
> To be complete I should also add that there are additional states such
> as S0ix and D0ix but that's likely not enabled on your HDaudio-based
> platform. There's also G, P and C states if you really want to get into
> the complicated stuff [1]

Very interesting. Thanks!

>
> Hope this helps
> -Pierre
>
> [1]
> https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Power_states