[Sound-open-firmware] About sof and D0 D3 states, 'standby' and 'suspend to RAM'
Hello,
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)?
I have digged into the code and found the debug line in sound/soc/sof/intel/hda-codec.c: dev_dbg(bus->dev, "Turning i915 HDAC power %d\n", enable); and function hda_suspend is in hda-dsp.c: static int hda_suspend(struct snd_sof_dev *sdev, bool runtime_suspend)
Regards, Josep
[1]: https://thesofproject.github.io/latest/developer_guides/linux_driver/archite... [2]: https://www.kernel.org/doc/html/v5.6/admin-guide/pm/sleep-states.html#suspen... [3]: Log from a session in a laptop working on its battery (only D0 D3 transition debug lines): ++++++++++++++++++++++++++++ Apr 23 08:06:20 debian kernel: [ 1357.524900] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:23 debian kernel: [ 1359.967511] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:06:29 debian kernel: [ 1366.697617] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:32 debian kernel: [ 1368.976763] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:07:41 debian kernel: [ 1438.758013] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:07:44 debian kernel: [ 1440.968094] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:29 debian kernel: [ 1486.346591] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:32 debian kernel: [ 1488.968805] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:33 debian kernel: [ 1489.970170] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:35 debian kernel: [ 1492.134071] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:09:43 debian kernel: [ 1560.535211] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:09:46 debian kernel: [ 1563.180713] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:12 debian kernel: [ 1649.719864] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:15 debian kernel: [ 1652.347401] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:23 debian kernel: [ 1660.328147] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:26 debian kernel: [ 1662.895611] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:38 debian kernel: [ 1675.404116] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:41 debian kernel: [ 1678.023978] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:43 debian kernel: [ 1680.128389] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:45 debian kernel: [ 1682.563802] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:46 debian kernel: [ 1683.187391] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:48 debian kernel: [ 1685.358684] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:52 debian kernel: [ 1689.704048] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:55 debian kernel: [ 1692.350057] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:56 debian kernel: [ 1693.056443] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:58 debian kernel: [ 1695.315083] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:28 debian kernel: [ 1725.232502] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:30 debian kernel: [ 1727.379811] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:35 debian kernel: [ 1732.240686] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:38 debian kernel: [ 1734.816780] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:39 debian kernel: [ 1736.719892] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:42 debian kernel: [ 1739.340736] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:51 debian kernel: [ 1748.048546] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:53 debian kernel: [ 1750.688659] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:58 debian kernel: [ 1755.075835] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
I think the high level intent is to only have the DSP on when it's actually doing something, or a little while after in case you want to e.g. play multiple songs in a row. Keeping the DSP off when unused is a power saving measure. And this is done even without the host OS ever entering in a suspend state -- if you just browse the Internet and don't need sound the DSP doesn't need to be on, thus SOF will turn off for that moment and will turn back on as needed -- a notification sound or you starting to play music.
________________________________________ From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org on behalf of josep lladonosa capell jlladonosa@gmail.com Sent: Thursday, April 23, 2020 8:12 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] About sof and D0 D3 states, 'standby' and 'suspend to RAM'
Hello,
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)?
I have digged into the code and found the debug line in sound/soc/sof/intel/hda-codec.c: dev_dbg(bus->dev, "Turning i915 HDAC power %d\n", enable); and function hda_suspend is in hda-dsp.c: static int hda_suspend(struct snd_sof_dev *sdev, bool runtime_suspend)
Regards, Josep
[1]: https://thesofproject.github.io/latest/developer_guides/linux_driver/archite... [2]: https://www.kernel.org/doc/html/v5.6/admin-guide/pm/sleep-states.html#suspen... [3]: Log from a session in a laptop working on its battery (only D0 D3 transition debug lines): ++++++++++++++++++++++++++++ Apr 23 08:06:20 debian kernel: [ 1357.524900] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:23 debian kernel: [ 1359.967511] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:06:29 debian kernel: [ 1366.697617] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:32 debian kernel: [ 1368.976763] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:07:41 debian kernel: [ 1438.758013] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:07:44 debian kernel: [ 1440.968094] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:29 debian kernel: [ 1486.346591] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:32 debian kernel: [ 1488.968805] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:33 debian kernel: [ 1489.970170] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:35 debian kernel: [ 1492.134071] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:09:43 debian kernel: [ 1560.535211] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:09:46 debian kernel: [ 1563.180713] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:12 debian kernel: [ 1649.719864] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:15 debian kernel: [ 1652.347401] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:23 debian kernel: [ 1660.328147] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:26 debian kernel: [ 1662.895611] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:38 debian kernel: [ 1675.404116] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:41 debian kernel: [ 1678.023978] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:43 debian kernel: [ 1680.128389] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:45 debian kernel: [ 1682.563802] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:46 debian kernel: [ 1683.187391] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:48 debian kernel: [ 1685.358684] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:52 debian kernel: [ 1689.704048] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:55 debian kernel: [ 1692.350057] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:56 debian kernel: [ 1693.056443] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:58 debian kernel: [ 1695.315083] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:28 debian kernel: [ 1725.232502] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:30 debian kernel: [ 1727.379811] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:35 debian kernel: [ 1732.240686] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:38 debian kernel: [ 1734.816780] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:39 debian kernel: [ 1736.719892] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:42 debian kernel: [ 1739.340736] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:51 debian kernel: [ 1748.048546] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:53 debian kernel: [ 1750.688659] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:58 debian kernel: [ 1755.075835] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
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.
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.
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]
Hope this helps -Pierre
[1] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Pow...
hank you, Paul, Pierre.
Missatge de Pierre-Louis Bossart pierre-louis.bossart@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#Pow...
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
we've removed all these traces already, 5.7-rc1 should already not show this any longer.
participants (3)
-
josep lladonosa capell -
Paul Olaru (OSS) -
Pierre-Louis Bossart