- Sound-open-firmware - mailman.alsa-project.org

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

Re: [Sound-open-firmware] [sof] how to use the latest rimage in sof ?
by Daniel Baluta 14 Sep '21

14 Sep '21

Adding SOF mailing list and Marc, AFAIK rimage is a submodule of the sof repo. Either you update the git submodule manually or use ./scripts/xtensa-build-all.sh script which I think it updates the rimage before starting compilation. ________________________________ From: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng(a)mediatek.com> Sent: Tuesday, September 14, 2021 4:41 PM To: Daniel Baluta <daniel.baluta(a)nxp.com> Subject: [sof] how to use the latest rimage in sof ? Hi Daniel, This is Allen Cheng from Mediatek. Sorry to bother you. When I use the latest sof. I find the rimage is not the latest one. The rimag verson be fixed in a certain commits. Could you give me some advice? Is there anything I didn’t notice, please let me know. Thanks. ************* 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!

2 1

Re: [Sound-open-firmware] [PATCH linux-next] ASoC: SOF: intel: remove duplicate include
by Mark Brown 25 Aug '21

25 Aug '21

On Mon, 23 Aug 2021 20:00:15 -0700, CGEL wrote: > From: Changcheng Deng <deng.changcheng(a)zte.com.cn> > > Clean up the following includecheck warning: > > ./sound/soc/sof/intel/pci-tng.c: shim.h is included more than once. > > No functional change. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: intel: remove duplicate include commit: 0be10d7122ceb8f322086283420a59ee89c1947f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [Sound-open-firmware] [PATCH linux-next] ASoC: SOF: intel: remove duplicate include
by Pierre-Louis Bossart 24 Aug '21

24 Aug '21

On 8/23/21 10:00 PM, CGEL wrote: > From: Changcheng Deng <deng.changcheng(a)zte.com.cn> > > Clean up the following includecheck warning: > > ./sound/soc/sof/intel/pci-tng.c: shim.h is included more than once. > > No functional change. > > Reported-by: Zeal Robot <zealci(a)zte.com.cn> > Signed-off-by: Changcheng Deng <deng.changcheng(a)zte.com.cn> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > --- > sound/soc/sof/intel/pci-tng.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/sound/soc/sof/intel/pci-tng.c b/sound/soc/sof/intel/pci-tng.c > index 4ee1da3..4bded66 100644 > --- a/sound/soc/sof/intel/pci-tng.c > +++ b/sound/soc/sof/intel/pci-tng.c > @@ -15,7 +15,6 @@ > #include <sound/sof.h> > #include "../ops.h" > #include "atom.h" > -#include "shim.h" > #include "../sof-pci-dev.h" > #include "../sof-audio.h" > >

1 0

[Sound-open-firmware] Questions about XTOS & HAL
by Daniel Baluta 20 Aug '21

20 Aug '21

Hi Liam, Where did you get the initial sources for xtos or HAL that can be found in: * src/arch/xtensa/xtos * src/arch/xtensa/hal I wonder if they arrived with some documentation. We are preparing a presentation for Linaro Connect, to describe our effort of switching from XTOS to Zephyr [1] and we like to better understand how SOF uses xtos/hal/etc. So far example we would like to understand: 1) what is the role of HAL and why it is not inside the same binary as the XTOS? 2) what is the role of libreset.a and why it isnt implemented inside libxtos.a 3) in SOF presentations we've seen that the generic micro kernel used by SOF comes with threads, semaphores, workqueus, mutexes. Are these primitives implemented in the XTOS initial code? We couldn't find them in the xtos code that is inside SOF. thanks, Daniel. [1] https://events.pinetool.ai/2231/#sessions/67130?referrer%5Bpathname%5D=%2Fs… Linaro Virtual Connect Fall 2021<https://events.pinetool.ai/2231/#sessions/67130?referrer%5Bpathname%5D=%2Fs…> Linaro Virtual Connect Fall 2021 events.pinetool.ai       

1 0

Re: [Sound-open-firmware] [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue
by Pierre-Louis Bossart 18 Aug '21

18 Aug '21

On 8/18/21 7:07 AM, Mark Brown wrote: > On Tue, Aug 17, 2021 at 02:00:57PM -0500, Pierre-Louis Bossart wrote: > >> +++ b/sound/soc/sof/core.c >> @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) >> >> sdev->probe_completed = true; >> >> + /* kick-off re-probing of deferred devices */ >> + driver_deferred_probe_trigger(); >> + > > I think we should move this into snd_soc_register_component() - the same > issue could occur with any other component, the only other thing I can > see kicking in here is the machine driver registration but that ought to > kick probe itself anyway. Or is there some other case here? Thanks for the suggestion Mark, it would be more consistent indeed to kick a re-evaluation of the deferred probe list when ASoC components are successfully registered with something like this: diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c830e96afba2..9d6feea7719c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2677,7 +2677,14 @@ int snd_soc_register_component(struct device *dev, if (ret < 0) return ret; - return snd_soc_add_component(component, dai_drv, num_dai); + ret = snd_soc_add_component(component, dai_drv, num_dai); + if (ret < 0) + return ret; + + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + + return 0; } EXPORT_SYMBOL_GPL(snd_soc_register_component); In the case of this SOF driver, it'd be completely equivalent to what this patch suggested, the snd_soc_register_component() is what we do last in the workqueue. In the case of 'regular' drivers, the component registration is typically done last as well before the end of the probe. This would result in 2 evaluations (one on successful ASoC component registration and one on successful probe), and maybe on the second evaluation there's nothing to do. I can't think of any negative side-effects.

1 0

[Sound-open-firmware] [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue
by Pierre-Louis Bossart 17 Aug '21

17 Aug '21

Audio drivers such as HDaudio legacy and SOF rely on a workqueue to split the probe into two, with a first pass returning success immediately, and the second pass taking a lot more time due to the use of request_module() and the DSP initializations. This workqueue-based solution helps deal with conflicting requirements a) other drivers should not be blocked by a long probe b) a PROBE_PREFER_ASYNCHRONOUS probe_type is explicitly not allowed to avoid a deadlock when request_module() is used. This patch makes sure the deferred probe framework is triggered when the provider of resources successfully completes its initialization. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c index 3e4dd4a86363..cecc0e914807 100644 --- a/sound/soc/sof/core.c +++ b/sound/soc/sof/core.c @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) sdev->probe_completed = true; + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + return 0; fw_trace_err: -- 2.25.1

1 0