Re: [PATCH v2 6/9] ASoC: tegra: add Tegra186 based DSPK driver

From: Sameer Pujar
Date: Mon Feb 10 2020 - 09:49:22 EST




On 2/10/2020 5:52 PM, Jon Hunter wrote:
On 10/02/2020 11:15, Sameer Pujar wrote:

On 2/7/2020 11:52 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments


07.02.2020 14:26, Sameer Pujar ÐÐÑÐÑ:
On 2/6/2020 10:45 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments


30.01.2020 13:33, Sameer Pujar ÐÐÑÐÑ:
+static const struct dev_pm_ops tegra186_dspk_pm_ops = {
+ÂÂÂÂ SET_RUNTIME_PM_OPS(tegra186_dspk_runtime_suspend,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ tegra186_dspk_runtime_resume, NULL)
+ÂÂÂÂ SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ pm_runtime_force_resume)
+};
Could you please explain why drivers need the "late" system sleep?
It was done to ensure core drivers are suspended first and defer the
codec driver suspend
Suspend order is opposite to the drivers registration order. If there is
no real problem with that, then you should use the default suspend
level. Please don't try to fix a non-existent problems.
No. This was done specifically to allow sound core to first stop any
ongoing audio activity during normal suspend and ensure a safe suspend
of AHUB devices by doing a LATE suspend.
What Dmitry is saying is that if the DSPK driver is registered after the
sound core then we will not need to suspend in the late phase. The DSPK
device should only be registered once the sound core is loaded, because
otherwise we should fail to register it with the sound core. So I don't
think we need this to be late afterall.

I was originally thinking if DMA is the main reason for using LATE suspend for audio drivers as well. I did a small sanity check and appears normal suspend is fine. I will update the drivers with normal suspend. If we come across any issue later, it can be addressed separately. Thanks Dmitry and Jon.

Jon