Sound-open-firmware October 2021

sound-open-firmware@alsa-project.org

5 participants
5 discussions

Re: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof
by Pierre-Louis Bossart 21 Oct '21

21 Oct '21

> In sof-of-dev.c > static void sof_of_probe_complete(struct device *dev) > { > /* allow runtime_pm */ > pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS); > pm_runtime_use_autosuspend(dev); > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > > pm_runtime_mark_last_busy(dev); > pm_runtime_put_autosuspend(dev); this last line looks wrong it looks like the code in sof-of-dev.c is imbalanced. The last pm_runtime_put_autosuspend() is not matching any pm_runtime_get_sync(), is it? > } > > > After pm_runtime_put_autosuspend, the current device power usage count should minus one. (1->0) > > And wait SND_SOF_SUSPEND_DELAY_MS seconds, sof device will autosuspend (because the power usage count is 0 ). Indeed. We have this comment for the PCI case: /* follow recommendation in pci-driver.c to decrement usage counter */ pm_runtime_put_noidle(dev); and a matching one for remove: /* follow recommendation in pci-driver.c to increment usage counter */ if (snd_sof_device_probe_completed(&pci->dev) && !(sof_pci_debug & SOF_PCI_DISABLE_PM_RUNTIME)) pm_runtime_get_noresume(&pci->dev); In the general case, I don't know why you would need to add a put_autosuspend in the probe complete, even for cases where the device does support pm_runtime. Having a mark_last_busy() is fine though, it would reset the counters and let the autosuspend happen at a later time. But I would call this before enable for consistency. Can you try with the sequence below in probe_complete? pm_runtime_set_autosuspend_delay(dev, DELAY_MS); pm_runtime_use_autosuspend(dev); pm_runtime_mark_last_busy(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev);

2 1

Re: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof
by Daniel Baluta 20 Oct '21

20 Oct '21

Hello, My understanding is that if you do not provide the runtime suspend/resume callbacks the device should not enter suspend state. Isn't that happening with this line: if (!sof_ops(sdev)->runtime_suspend || !sof_ops(sdev)->runtime_resume) { pm_runtime_get_noresume(sdev->dev); } Daniel. ________________________________ From: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng(a)mediatek.com> Sent: Wednesday, October 20, 2021 9:21 AM To: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>; Daniel Baluta <daniel.baluta(a)nxp.com> Cc: sound-open-firmware(a)alsa-project.org <sound-open-firmware(a)alsa-project.org>; YC Hung (洪堯俊) <yc.hung(a)mediatek.com>; Nathan Chung (仲崇寧) <nathan.chung(a)mediatek.com>; Randy Wu (吳柏樹) <Randy.Wu(a)mediatek.com> Subject: RE: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof Hi Pierre and Daniel, I have a problem. If our DSP don't support pm_runtime, We will not declare pm_runtime callbacks set. In core.c /* * Some platforms in SOF, ex: BYT, may not have their platform PM * callbacks set. Increment the usage count so as to * prevent the device from entering runtime suspend. */ if (!sof_ops(sdev)->runtime_suspend || !sof_ops(sdev)->runtime_resume) { pm_runtime_get_noresume(sdev->dev); } After pm_runtime_get_noresume, the current device power usage count should add one. (0->1) In sof-of-dev.c static void sof_of_probe_complete(struct device *dev) { /* allow runtime_pm */ pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS); pm_runtime_use_autosuspend(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); pm_runtime_mark_last_busy(dev); pm_runtime_put_autosuspend(dev); } After pm_runtime_put_autosuspend, the current device power usage count should minus one. (1->0) And wait SND_SOF_SUSPEND_DELAY_MS seconds, sof device will autosuspend (because the power usage count is 0 ). 1) So if we don't have the runtime suspsend mode in mtk DSP, is that ok? 2) If the question 1) is ok, what's kind way would be better to prevent autosuspend? Add a new pm_runtime_get_noresume after fw launching or use the below sof_of_probe_complete function. (sof-acpi-dev.c) static void sof_acpi_probe_complete(struct device *dev) { dev_dbg(dev, "Completing SOF ACPI probe"); if (sof_acpi_debug & SOF_ACPI_DISABLE_PM_RUNTIME) return; /* allow runtime_pm */ pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS); pm_runtime_use_autosuspend(dev); pm_runtime_enable(dev); } I would appreciate it if you could give me some advice. :) Thnaks. -----Original Message----- From: Allen-KH Cheng (程冠勳) Sent: Wednesday, October 6, 2021 9:48 PM To: Pierre-Louis Bossart; Daniel Baluta Cc: sound-open-firmware(a)alsa-project.org; YC Hung (洪堯俊); Nathan Chung (仲崇寧); Randy Wu (吳柏樹) Subject: RE: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof Hi Pierre and Daniel, Thank you for your helpful feedback and clear explanation. I will check our current implementation. Thanks. -----Original Message----- From: Pierre-Louis Bossart [mailto:pierre-louis.bossart@linux.intel.com] Sent: Wednesday, October 6, 2021 1:21 AM To: Daniel Baluta; Allen-KH Cheng (程冠勳) Cc: sound-open-firmware(a)alsa-project.org; YC Hung (洪堯俊) Subject: Re: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof > Normally, we set power domain device node in DTS for sof device driver. > > > > So the device power will be enabled by pm_runtime manager before device probe. > > > > if we don’t call pm_runtime_get_sync in snd_sof_probe. > > > > The device power should disable after snd_sof_probe done. (Because > reference count is zero) The current design is - pm_runtime is only allowed *AFTER* the probe completes. - we enable auto_suspend with a timeout, typically 3 seconds - we mark when the device is last busy, including at the end of the probe, so the transition to 'suspended' only happens with a delay. - when the ALSA core needs a component, it'll call pm_runtime_get_sync() and the resume happens there. - the only cases where you will see calls to pm_runtime_get_sync() is for debug/trace or ALSA controls. Hope this helps -Pierre ************* MEDIATEK Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!

1 0

[Sound-open-firmware] [PATCH 0/4] Introduce new SOF helpers
by Daniel Baluta 07 Oct '21

07 Oct '21

From: Daniel Baluta <daniel.baluta(a)nxp.com> This patchseries adds new helpers in order to reduce code duplication and prepare for compress audio support with SOF. Bud Liviu-Alexandru (1): ASoC: SOF: Make Intel IPC stream ops generic Daniel Baluta (3): ASoC: SOF: Introduce snd_sof_mailbox_read / snd_sof_mailbox_write callbacks ASoC: SOF: imx: Use newly introduced generic IPC stream ops ASoC: SOF: Introduce fragment elapsed notification API sound/soc/sof/Kconfig | 4 ++ sound/soc/sof/Makefile | 3 +- sound/soc/sof/compress.c | 51 +++++++++++++++++++ sound/soc/sof/imx/Kconfig | 2 + sound/soc/sof/imx/imx8.c | 39 +++++++------- sound/soc/sof/imx/imx8m.c | 26 ++++------ sound/soc/sof/intel/Makefile | 3 -- sound/soc/sof/intel/apl.c | 4 ++ sound/soc/sof/intel/bdw.c | 12 +++-- sound/soc/sof/intel/byt.c | 24 ++++++--- sound/soc/sof/intel/cnl.c | 4 ++ sound/soc/sof/intel/icl.c | 4 ++ sound/soc/sof/intel/pci-tng.c | 12 +++-- sound/soc/sof/intel/tgl.c | 4 ++ sound/soc/sof/ipc.c | 6 ++- sound/soc/sof/ops.h | 15 ++++++ sound/soc/sof/pcm.c | 7 ++- sound/soc/sof/sof-audio.h | 11 +++- sound/soc/sof/sof-priv.h | 28 ++++++---- .../sof/{intel/intel-ipc.c => stream-ipc.c} | 50 +++++++++--------- sound/soc/sof/topology.c | 6 ++- 21 files changed, 218 insertions(+), 97 deletions(-) create mode 100644 sound/soc/sof/compress.c rename sound/soc/sof/{intel/intel-ipc.c => stream-ipc.c} (58%) -- 2.27.0

2 5

Re: [Sound-open-firmware] [SOF][KERNEL] pm_runtime flow in sof
by Daniel Baluta 05 Oct '21

05 Oct '21

Hi Allen, Not sure I understood your question correctly. But here is how I understood things happens. PM manager enables PM domain before sof_probe_continue. We then have: sof_probe_continue -------> sof_probe_continue -------> sof_probe_run [ At this point DSP is running] sof_probe_complete [ AT this point RUNTIME PM is set and the DSP will enter runtime suspend if nothing happens in the next 2 seconds ] After two seconds the DSP will enter runtime suspend and the PM domain will be put to off by PM core. Next, if anyone tries to use the DSP (via aplay for example) the RUNTIME PM RESUME will be called the PM domain will be turned ON the firmware will be booted again and start to run normally. Hope this is clear. Please also Cc: sound-open-firmware(a)alsa-project.org for your next emails thanks, Daniel. ________________________________ From: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng(a)mediatek.com> Sent: Monday, October 4, 2021 2:03 PM To: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: YC Hung (洪堯俊) <yc.hung(a)mediatek.com> Subject: [SOF][KERNEL] pm_runtime flow in sof Hi Daniel, This is Allen Cheng from Mediatek. Sorry to bother you. In sof_probe_continue static int sof_probe_continue(struct snd_sof_dev *sdev) { struct snd_sof_pdata *plat_data = sdev->pdata; int ret; /* probe the DSP hardware */ ret = snd_sof_probe(sdev); if (ret < 0) { dev_err(sdev->dev, "error: failed to probe DSP %d\n", ret); return ret; } …. /* init the IPC */ sdev->ipc = snd_sof_ipc_init(sdev); if (!sdev->ipc) { ret = -ENOMEM; dev_err(sdev->dev, "error: failed to init DSP IPC %d\n", ret); goto ipc_err; } /* load the firmware */ ret = snd_sof_load_firmware(sdev); if (ret < 0) { dev_err(sdev->dev, "error: failed to load DSP firmware %d\n", ret); goto fw_load_err; } sdev->fw_state = SOF_FW_BOOT_IN_PROGRESS; /* * Boot the firmware. The FW boot status will be modified * in snd_sof_run_firmware() depending on the outcome. */ ret = snd_sof_run_firmware(sdev); if (ret < 0) { dev_err(sdev->dev, "error: failed to boot DSP firmware %d\n", ret); goto fw_run_err; } …….. } Normally, we set power domain device node in DTS for sof device driver. So the device power will be enabled by pm_runtime manager before device probe. if we don’t call pm_runtime_get_sync in snd_sof_probe. The device power should disable after snd_sof_probe done. (Because reference count is zero) I wonder that how does imx driver handle this situation . Because the sof_probe_continue will do snd_sof_load_firmware and snd_sof_run_firmware after snd_sof_probe. I think it’s impossible that we load fw and launch when DSP is power off . I would appreciate it if you could give me some advice. :) Thnaks. ************* MEDIATEK Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!

1 0

[Sound-open-firmware] [PATCH AUTOSEL 5.14 15/40] ASoC: SOF: loader: release_firmware() on load failure to avoid batching
by Sasha Levin 05 Oct '21

05 Oct '21

From: Marc Herbert <marc.herbert(a)intel.com> [ Upstream commit 8a8e1813ffc35111fc0b6db49968ceb0e1615ced ] Invoke release_firmware() when the firmware fails to boot in sof_probe_continue(). The request_firmware() framework must be informed of failures in sof_probe_continue() otherwise its internal "batching" feature (different from caching) cached the firmware image forever. Attempts to correct the file in /lib/firmware/ were then silently and confusingly ignored until the next reboot. Unloading the drivers did not help because from their disconnected perspective the firmware had failed so there was nothing to release. Also leverage the new snd_sof_fw_unload() function to simplify the snd_sof_device_remove() function. Signed-off-by: Marc Herbert <marc.herbert(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20210916085008.28929-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/core.c | 4 +--- sound/soc/sof/loader.c | 2 ++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c index 3e4dd4a86363..59d0d7b2b55c 100644 --- a/sound/soc/sof/core.c +++ b/sound/soc/sof/core.c @@ -371,7 +371,6 @@ int snd_sof_device_remove(struct device *dev) dev_warn(dev, "error: %d failed to prepare DSP for device removal", ret); - snd_sof_fw_unload(sdev); snd_sof_ipc_free(sdev); snd_sof_free_debug(sdev); snd_sof_free_trace(sdev); @@ -394,8 +393,7 @@ int snd_sof_device_remove(struct device *dev) snd_sof_remove(sdev); /* release firmware */ - release_firmware(pdata->fw); - pdata->fw = NULL; + snd_sof_fw_unload(sdev); return 0; } diff --git a/sound/soc/sof/loader.c b/sound/soc/sof/loader.c index 2b38a77cd594..9c3f251a0dd0 100644 --- a/sound/soc/sof/loader.c +++ b/sound/soc/sof/loader.c @@ -880,5 +880,7 @@ EXPORT_SYMBOL(snd_sof_run_firmware); void snd_sof_fw_unload(struct snd_sof_dev *sdev) { /* TODO: support module unloading at runtime */ + release_firmware(sdev->pdata->fw); + sdev->pdata->fw = NULL; } EXPORT_SYMBOL(snd_sof_fw_unload); -- 2.33.0

1 0

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware October 2021