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

[Sound-open-firmware] [PATCH v5 0/3] This patches provide ADSP IPC support for MT8195
by allen-kh.cheng 26 Nov '21

26 Nov '21

Mediatek ADSP IPC is used to send notification or short message between processors with dsp.· It will place the message to the share buffer and will access the ADSP mailbox registers to kick dsp. Two mailboxes used to send notification or short message between processors with dsp changes since v4: - use switch ... case in adsp_ipc_recv - add error handling path for chan_name pointer - refine some code to be concise changes since v3: - reorder MTK_ADSP_IPC_MBOX config - remove some redundant code - remove lock in mtk-adsp-mailbox changes since v2: - separate adsp_mailbox into two instances changes since v1: - fix dt_binding_check error Allen-KH Cheng (3): dt-bindings: mediatek: add adsp-mbox document firmware: mediatek: add adsp ipc protocol interface mailbox: mediatek: add support for adsp mailbox controller .../bindings/mailbox/mtk,adsp-mbox.yaml | 52 +++++ drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/mediatek/Kconfig | 9 + drivers/firmware/mediatek/Makefile | 2 + drivers/firmware/mediatek/mtk-adsp-ipc.c | 138 ++++++++++++++ drivers/mailbox/Kconfig | 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mtk-adsp-mailbox.c | 178 ++++++++++++++++++ .../linux/firmware/mediatek/mtk-adsp-ipc.h | 70 +++++++ 10 files changed, 460 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml create mode 100644 drivers/firmware/mediatek/Kconfig create mode 100644 drivers/firmware/mediatek/Makefile create mode 100644 drivers/firmware/mediatek/mtk-adsp-ipc.c create mode 100644 drivers/mailbox/mtk-adsp-mailbox.c create mode 100644 include/linux/firmware/mediatek/mtk-adsp-ipc.h -- 2.18.0

2 5

[Sound-open-firmware] [PATCH v4 0/3] This patches provide ADSP IPC support for MT8195
by allen-kh.cheng 26 Nov '21

26 Nov '21

Mediatek ADSP IPC is used to send notification or short message between processors with dsp.· It will place the message to the share buffer and will access the ADSP mailbox registers to kick dsp. Two mailboxes used to send notification or short message between processors with dsp changes since v3: - reorder MTK_ADSP_IPC_MBOX config - remove some redundant code - remove lock in mtk-adsp-mailbox changes since v2: - seperate adsp_mailbox into two instances changes since v1: - fix dt_binding_check error Allen-KH Cheng (3): dt-bindings: mediatek: add adsp-mbox document firmware: mediatek: add adsp ipc protocol interface mailbox: mediatek: add support for adsp mailbox controller .../bindings/mailbox/mtk,adsp-mbox.yaml | 52 +++++ drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/mediatek/Kconfig | 9 + drivers/firmware/mediatek/Makefile | 2 + drivers/firmware/mediatek/mtk-adsp-ipc.c | 132 +++++++++++++ drivers/mailbox/Kconfig | 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mtk-adsp-mailbox.c | 184 ++++++++++++++++++ .../linux/firmware/mediatek/mtk-adsp-ipc.h | 70 +++++++ 10 files changed, 460 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml create mode 100644 drivers/firmware/mediatek/Kconfig create mode 100644 drivers/firmware/mediatek/Makefile create mode 100644 drivers/firmware/mediatek/mtk-adsp-ipc.c create mode 100644 drivers/mailbox/mtk-adsp-mailbox.c create mode 100644 include/linux/firmware/mediatek/mtk-adsp-ipc.h -- 2.18.0

2 5

[Sound-open-firmware] [PATCH -next] ASoC: SOF: mediatek: Add missing of_node_put() in platform_parse_resource()
by Yang Yingliang 25 Nov '21

25 Nov '21

The node pointer is returned by of_parse_phandle() with refcount incremented in platform_parse_resource(). Calling of_node_put() to aovid the refcount leak. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- sound/soc/sof/mediatek/mt8195/mt8195.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/sof/mediatek/mt8195/mt8195.c b/sound/soc/sof/mediatek/mt8195/mt8195.c index 40e5a25875a6..55d9812870a4 100644 --- a/sound/soc/sof/mediatek/mt8195/mt8195.c +++ b/sound/soc/sof/mediatek/mt8195/mt8195.c @@ -43,6 +43,7 @@ static int platform_parse_resource(struct platform_device *pdev, void *data) } ret = of_address_to_resource(mem_region, 0, &res); + of_node_put(mem_region); if (ret) { dev_err(dev, "of_address_to_resource dma failed\n"); return ret; @@ -64,6 +65,7 @@ static int platform_parse_resource(struct platform_device *pdev, void *data) } ret = of_address_to_resource(mem_region, 0, &res); + of_node_put(mem_region); if (ret) { dev_err(dev, "of_address_to_resource sysmem failed\n"); return ret; -- 2.25.1

2 1

Re: [Sound-open-firmware] [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller
by allen-kh.cheng 25 Nov '21

25 Nov '21

On Thu, 2021-11-25 at 14:23 +0800, Tzung-Bi Shih wrote: > > On Thu, Nov 25, 2021 at 09:51:27AM +0800, allen-kh.cheng wrote: > > > > On Wed, 2021-11-24 at 18:25 +0800, Tzung-Bi Shih wrote: > > > > > > > > On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen- > > > > kh.cheng wrote: > > > > > > > > > > > > +static int mtk_adsp_mbox_send_data(struct > > > > > > mbox_chan *chan, > > > > > > > > > > > > > > > > > > > > void > > > > > > > > > > > > *data) > > > > > > > > > > > > +{ > > > > > > > > > > > > + struct adsp_mbox_ch_info *ch_info = chan- > > > > > > >con_priv; > > > > > > > > > > > > + void __iomem *reg = ch_info->va_reg; > > > > > > > > > > > > + > > > > > > > > > > > > + spin_lock(&ch_info->lock); > > > > > > > > > > > > + writel(ch_info->ipc_op_val, reg + > > > > > > MTK_ADSP_MBOX_IN_CMD); > > > > > > > > > > > > + spin_unlock(&ch_info->lock); > > > > > > > > > > > > > > > > > > > > Why does it need the lock? > > > > > > > > > > > > > > > > Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous > > > > operation? > > > > > > > > - If yes, I failed to understand why does it need the > > > > > > > > lock. Every > > > > > > > > calls to mtk_adsp_mbox_send_data() should wait for the > > > > data > > > > > > > > > > > > > > > transfer > > > > > > > > completion. > > > > > > > > - If no, I also failed to understand > > > > > > > > > > > > > > > why. mtk_adsp_mbox_send_data() > > > > > > > > has no way to be aware of the transfer > > > > completion. Would > > > > > > > > expect a > > > > > > > > loop for checking the completion for the case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In ADSP MBOX IPC flow, > > > > > > > > Host would call mbox send data when the shared data transfer > > > > completed. > > > > > > > > (mtk_adsp_mbox_send_data will notice client using > > > > MTK_ADSP_MBOX_IN_CMD) > > > > > > > > It’s more like a signal. > > > > > > > > In general case, > > > > > > > > There may be some hosts use the same mbox channel. > > > > > > > > I think it’s better using lock to protect access to > > > > MTK_ADSP_MBOX_IN_CMD registers > > > > > I still failed to understand. What if 2 hosts notify the same > client > > by writing MTK_ADSP_MBOX_IN_CMD at the same time? Hi Tzung-Bi, After I think carefully. There is no need to add lock in mtk_adsp_mbox_send_data. In our dsp ipc design, we only have one host(ap) and one client(dsp). If sof ip message transfer is complete, host will use mbox notice dsp message arrived. (MTK_ADSP_MBOX_IN_CMD is signal to trigger mbox irq) I will remove this in next version.

1 0

Re: [Sound-open-firmware] [Bug 214995] New: Sof audio didn't recognize Intel Smart Sound (SST) speakers, microphone and headphone jack
by Pierre-Louis Bossart 15 Nov '21

15 Nov '21

On 11/12/21 4:24 PM, Bjorn Helgaas wrote: > On Fri, Nov 12, 2021 at 09:11:45AM +0000, bugzilla-daemon(a)bugzilla.kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=214995 >> >> Bug ID: 214995 >> Summary: Sof audio didn't recognize Intel Smart Sound (SST) >> speakers, microphone and headphone jack >> Product: Drivers >> Version: 2.5 >> Kernel Version: 5.11.0-40-generic >> Hardware: Intel >> OS: Linux >> Tree: Mainline >> Status: NEW >> Severity: high >> Priority: P1 >> Component: PCI >> Assignee: drivers_pci(a)kernel-bugs.osdl.org >> Reporter: nicolarevelant44(a)gmail.com >> Regression: No >> >> Created attachment 299549 >> --> https://bugzilla.kernel.org/attachment.cgi?id=299549&action=edit >> The output of dmesg and lspci -v >> >> I have a Huawei Matebook D15 notebook with Intel Smart Sound Technology as >> sound card. SST includes speakers, microphone and headphone jack so none of the >> 3 work. Bluetooth and USB headphones work. I have already tried to change >> "options snd_intel_dspcfg dsp_driver" and reload alsa (alsa reload) for each >> value but nothing (only small changes in dmesg). >> The first lines of dmesg_dump.txt are errors because of the 'alsa reload' >> command. The log is verbose because I add some options from this web page: >> https://thesofproject.github.io/latest/getting_started/intel_debug/suggesti… >> >> My sound card is listed in PCI so the last lines of dmesg_dump.txt are the >> output of the 'lspci -v' command >> >> aplay -l shows only 3 HDMI outputs with sof-hda-dsp > > Hi Nicola, > > Thanks very much for the report and sorry for the problem. > > It's possible there's a power management issue, e.g., reads to the > 00:1f.3 device are timing out because the device is in D3cold, but I > can't tell from the part of the dmesg log you attached. In that case, > reads will generally return ~0 (0xffffffff), but it looks like some > reads *do* return valid data, e.g., > > sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 > sof-audio-pci 0000:00:1f.3: found ML capability at 0xc00 > > I don't see an obvious PCI core connection here, so I cc'd the SOF > maintainers in case they have any insight. > > - It looks like you're running v5.11.0. Can you reproduce the same > problem on a current kernel, e.g., v5.15? It's possible the > problem has been fixed since v5.11. > > - Did this ever work? In other words, is this a regression? If so, > what's the newest kernel you know of that *did* work? In the > worst case, we could bisect to identify a change that broke it. > > - It might be useful if you could attach the complete dmesg log and > output of "sudo lspci -vv" to the bugzilla. That seems like a known issue already tracked at https://github.com/thesofproject/linux/issues/3248 There's a set of devices based on the ES8316/36 I2S audio codec which needs dedicated quirks. In the existing reports the Huawei Matebook D15 is listed as using that codec. The latest experimental code we have is here: https://github.com/thesofproject/linux/pull/3107/commits If confirmed, can we track this on GitHub so that all results for this sort of devices are collected in one place? Thanks!

1 0

[Sound-open-firmware] [PATCH] ASoC: SOF: build compression interface into snd_sof.ko
by Arnd Bergmann 12 Nov '21

12 Nov '21

From: Arnd Bergmann <arnd(a)arndb.de> With CONFIG_SND_SOC_SOF_COMPRESS=m, the compression code is not built into a the main SOF driver when that is built-in: x86_64-linux-ld: sound/soc/sof/ipc.o: in function `ipc_stream_message': ipc.c:(.text+0x5a2): undefined reference to `snd_sof_compr_fragment_elapsed' x86_64-linux-ld: sound/soc/sof/topology.o: in function `sof_dai_load': topology.c:(.text+0x32d1): undefined reference to `snd_sof_compr_init_elapsed_work' x86_64-linux-ld: topology.c:(.text+0x32e1): undefined reference to `snd_sof_compr_init_elapsed_work' Make this a 'bool' symbol so it just decides whether the code gets built at all. Fixes: 858f7a5c45ca ("ASoC: SOF: Introduce fragment elapsed notification API") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/sof/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig index 6bb4db87af03..041c54639c4d 100644 --- a/sound/soc/sof/Kconfig +++ b/sound/soc/sof/Kconfig @@ -47,7 +47,7 @@ config SND_SOC_SOF_OF Say Y if you need this option. If unsure select "N". config SND_SOC_SOF_COMPRESS - tristate + bool select SND_SOC_COMPRESS config SND_SOC_SOF_DEBUG_PROBES -- 2.29.2

4 7

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