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@mediatek.com Sent: Wednesday, October 20, 2021 9:21 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; Daniel Baluta daniel.baluta@nxp.com Cc: sound-open-firmware@alsa-project.org sound-open-firmware@alsa-project.org; YC Hung (洪堯俊) yc.hung@mediatek.com; Nathan Chung (仲崇寧) nathan.chung@mediatek.com; Randy Wu (吳柏樹) Randy.Wu@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@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@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!