On system suspend / resume we always power up the DSP and boot the
firmware, which is not strictly needed as right after the firmware booted
up we power the DSP down again on suspend and we also power it down after
resume after some inactivity.
Out of caution, add a new platform descriptor flag to enable on-demand
DSP boot since this might not work without changes to platform code on
certain platforms.
With the on-demand dsp boot enabled we will not boot the DSP and firmware
up on system or rpm resume, just enable audio subsystem since audio IPs,
like HDA and SoundWire might be needed (codecs suspend/resume operation).
Only boot up the DSP during the first hw_params() call when the DSP is
really going to be needed.
In this way we can handle the audio related use cases:
normal audio use (rpm suspend/resume)
system suspend/resume without active audio
system suspend/resume with active audio
system suspend/resume without active audio, and audio start before the rpm
suspend timeout
Add module option to force the on-demand DSP boot to allow it to be
disabled or enabled without kernel change for testing.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull sound updates from Takashi Iwai:
"At this time, it's an interesting mixture of changes for both old and
new stuff. Majority of changes are about ASoC (lots of systematic
changes for converting remove callbacks to void, and cleanups), while
we got the fixes and the enhancements of very old PCI cards, too.
Here are some highlights:
ALSA/ASoC Core:
- Continued effort of more ASoC core cleanups
- Minor improvements for XRUN handling in indirect PCM helpers
- Code refactoring of PCM core code
ASoC:
- Continued feature and simplification work on SOF, including
addition of a no-DSP mode for bringup, HDA MLink and extensions to
the IPC4 protocol
- Hibernation support for CS35L45
- More DT binding conversions
- Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas
R-Car Gen4, Rockchip RK3588 and TI TAS5733
ALSA:
- Lots of works for legacy emu10k1 and ymfpci PCI drivers
- PCM kselftest fixes and enhancements"
* tag 'sound-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (586 commits)
ALSA: emu10k1: use high-level I/O in set_filterQ()
ALSA: emu10k1: use high-level I/O functions also during init
ALSA: emu10k1: fix error handling in snd_audigy_i2c_volume_put()
ALSA: emu10k1: don't stop DSP in _snd_emu10k1_{,audigy_}init_efx()
ALSA: emu10k1: fix SNDRV_EMU10K1_IOCTL_SINGLE_STEP
ALSA: emu10k1: skip Sound Blaster-specific hacks for E-MU cards
ALSA: emu10k1: fixup DSP defines
ALSA: emu10k1: pull in some register definitions from kX-project
ALSA: emu10k1: remove some bogus defines
ALSA: emu10k1: eliminate some unused defines
ALSA: emu10k1: fix lineup of EMU_HANA_* defines
ALSA: emu10k1: comment updates
ALSA: emu10k1: fix snd_emu1010_fpga_read() input masking for rev2 cards
ALSA: emu10k1: remove unused emu->pcm_playback_efx_substream field
ALSA: emu10k1: remove unused `resume` parameter from snd_emu10k1_init()
ALSA: emu10k1: minor optimizations
ALSA: emu10k1: remove remaining cruft from snd_emu10k1_emu1010_init()
ALSA: emu10k1: remove apparently pointless EMU_HANA_OPTION_CARDS reads
ALSA: emu10k1: remove apparently pointless FPGA reads
ALSA: emu10k1: stop doing weird things with HCFG in snd_emu10k1_emu1010_init()
...
With PCI if the device was suspended it is brought back to full
power and then suspended again.
This doesn't happen when device is described via DT.
We need to make sure that we tear down pipelines only if the device
was previously active (thus the pipelines were setup).
Otherwise, we can break the use_count:
[ 219.009743] sof-audio-of-imx8m 3b6e8000.dsp:
sof_ipc3_tear_down_all_pipelines: widget PIPELINE.2.SAI3.IN is still in use: count -1
and after this everything stops working.
Fixes: d185e0689a ("ASoC: SOF: pm: Always tear down pipelines before DSP suspend")
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20230405092655.19587-1-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the system is suspended while a PCM is paused, it doesn't receive
the SUSPEND trigger. So, the SOF driver has to ensure that the PCM and
the widgets associated with the paused PCM are freed in the firmware
during suspend. This is handled in the
sof_tear_down_left_over_pipelines() call. But since the state of this
PCM is SUSPENDED, we end up clearing the prepared flag for the PCM
before freeing it. This results in IPC errors while freeing the widgets.
But because the widget use_counts are reset to 0 even though the IPC
fails, releasing the paused stream after resuming from suspend proceeds
normally.
Fix the IPC errors by removing the clearing of the prepared flag in
sof_set_hw_params_upon_resume(). In fact, we can remove the
sof_set_hw_params_upon_resume() and call
snd_sof_dsp_hw_params_upon_resume() directly. This will ensure that the
PCM is freed in the firmware before the IPC's for freeing the widgets
are sent.
BugLink: https://github.com/thesofproject/linux/issues/3543
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20220421203201.1550328-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
The aim of this series is to clean up, make it easier to interpret and less
'chatty' prints aimed for debugging errors.
For example currently the DSP/IPC dump is printed every time we have an IPC
timeout and it is posible to lost the first and more indicative dump to find the
rootcause.
Regards,
Peter
---
Peter Ujfalusi (18):
ASoC: SOF: debug: Swap the dsp_dump and ipc_dump sequence for
fw_exception
ASoC: SOF: ipc and dsp dump: Add markers for better visibility
ASoC: SOF: Print the dbg_dump and ipc_dump once to reduce kernel log
noise
ASoC: SOF: loader: Print the DSP dump if boot fails
ASoC: SOF: intel: atom: No need to do a DSP dump in atom_run()
ASoC: SOF: debug/ops: Move the IPC and DSP dump functions out from the
header
ASoC: SOF: debug: Add SOF_DBG_DUMP_OPTIONAL flag for DSP dumping
ASoC: SOF: intel: hda-loader: Use snd_sof_dsp_dbg_dump() for DSP dump
ASoC: SOF: Drop SOF_DBG_DUMP_FORCE_ERR_LEVEL and sof_dev_dbg_or_err
ASoC: SOF: debug: Print out the fw_state along with the DSP dump
ASoC: SOF: ipc: Re-enable dumps after successful IPC tx
ASoC: SOF: ops: Force DSP panic dumps to be printed
ASoC: SOF: Introduce macro to set the firmware state
ASoC: SOF: intel: hda: Drop 'error' prefix from error dump functions
ASoC: SOF: core: Clean up snd_sof_get_status() prints
ASoC: SOF: loader: Drop SOF_DBG_DUMP_REGS flag when firmware start
fails
ASoC: SOF: Intel: hda-loader: Drop SOF_DBG_DUMP_REGS flag from
dbg_dump calls
ASoC: SOF: Intel: hda: Dump registers and stack when SOF_DBG_DUMP_REGS
is set
Pierre-Louis Bossart (1):
ASoC: SOF: core: debug: force all processing on primary core
sound/soc/sof/core.c | 24 ++++++-------
sound/soc/sof/debug.c | 61 ++++++++++++++++++++++++++++++--
sound/soc/sof/intel/atom.c | 5 +--
sound/soc/sof/intel/hda-loader.c | 11 +++---
sound/soc/sof/intel/hda.c | 16 +++------
sound/soc/sof/ipc.c | 10 ++++--
sound/soc/sof/loader.c | 11 ++++--
sound/soc/sof/ops.c | 3 ++
sound/soc/sof/ops.h | 12 +------
sound/soc/sof/pm.c | 6 ++--
sound/soc/sof/sof-priv.h | 31 ++++++++++------
sound/soc/sof/topology.c | 6 ++++
12 files changed, 131 insertions(+), 65 deletions(-)
--
2.33.0
