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...