kernel/linux.git/sound/soc/sof/pm.c, branch v6.1.168

ASoC: SOF: pm: save io region state in case of errors in resume

2023-06-09T08:34:13+00:00

[ Upstream commit 171b53be635ac15d4feafeb33946035649b1ca14 ] If there are failures in DSP runtime resume, the device state will not reach active and this makes it impossible e.g. to retrieve a possible DSP panic dump via "exception" debugfs node. If CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE=y is set, the data in cache is stale. If debugfs cache is not used, the region simply cannot be read. To allow debugging these scenarios, update the debugfs cache contents in resume error handler. User-space can then later retrieve DSP panic and other state via debugfs (requires SOF debugfs cache to be enabled in build). Reported-by: Curtis Malainey

ASoC: SOF: pm: Tear down pipelines only if DSP was active

2023-04-26T12:28:44+00:00

commit 0b186bb06198653d74a141902a7739e0bde20cf4 upstream. 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: d185e0689abc ("ASoC: SOF: pm: Always tear down pipelines before DSP suspend") Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20230405092655.19587-1-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: pm: Always tear down pipelines before DSP suspend

2023-02-01T07:34:27+00:00

[ Upstream commit d185e0689abc98ef55fb7a7d75aa0c48a0ed5838 ] When the DSP is suspended while the firmware is in the crashed state, we skip tearing down the pipelines. This means that the widget reference counts will not get to reset to 0 before suspend. This will lead to errors with resuming audio after system resume. To fix this, invoke the tear_down_all_pipelines op before skipping to DSP suspend. Signed-off-by: Ranjani Sridharan Reviewed-by: Curtis Malainey Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20221220125629.8469-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: pm: Set target state earlier

2023-02-01T07:34:27+00:00

[ Upstream commit 6f95eec6fb89e195dbdf30de65553c7fc57d9372 ] If the DSP crashes before the system suspends, the setting of target state will be skipped because the firmware state will no longer be SOF_FW_BOOT_COMPLETE. This leads to the incorrect assumption that the DSP should suspend to D0I3 instead of suspending to D3. To fix this, set the target_state before we skip to DSP suspend even when the DSP has crashed. Signed-off-by: Ranjani Sridharan Reviewed-by: Curtis Malainey Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20221220125629.8469-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: pm: add definitions for S4 and S5 states

2022-06-24T15:21:50+00:00

We currently don't have a means to differentiate between S3, S4 and S5. Add definitions so that we have select different code paths depending on the target state in follow-up patches. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220616201818.130802-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

2022-06-24T15:21:50+00:00

The existing code only deals with S0 and S3, let's start adding S1 and S2. No functional change. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220616201818.130802-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Switch to IPC generic firmware tracing

2022-05-19T15:44:15+00:00

Introduce new, generic API for firmware tracing with sof_fw_trace_ prefix and switch to use it. At the same time the old IPC3 code can be dropped from trace.c, which is now a generic wrapper for the firmware tracing ops. Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220516104711.26115-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: remove incorrect clearing of prepared flag

2022-04-25T12:58:24+00:00

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 Reviewed-by: Péter Ujfalusi Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220421203201.1550328-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: disable dma trace in s0ix

2022-04-04T07:39:07+00:00

When system enters s0ix, the dma trace won't be used. Otherwise, the DMA will access the host memory, which will prevent entering S0ix. Driver has notified firmware not to send message through dma trace. Let's also trigger stop dma trace in driver side. Signed-off-by: Libin Yang Reviewed-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220330201926.1330402-8-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: extend the interface to stop DMA trace

2022-04-04T07:39:06+00:00

Change the interface to stop the DMA trace for suspend. Replace the snd_sof_init_trace_ipc() and snd_sof_release_trace() calls with more explicit interface for PM (the sole user for this interface). The new snd_sof_trace_suspend() call takes the target PM state as argument, allowing the trace implementation to decide how to handle the transition. Use this information to release DMA resources only if DSP is suspended and will not remain in D0. Signed-off-by: Peter Ujfalusi Signed-off-by: Libin Yang Reviewed-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220330201926.1330402-7-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown