From: Iuliana Prodan <[email protected]> The DSP suspend path currently waits unconditionally for a suspend ack from the firmware. This breaks firmwares that do not implement the mailbox-based CONFIRMATION handshake, as the DSP never responds and system suspend fails with -EBUSY.
The driver already uses the WAIT_FW_CONFIRMATION flag to indicate that the firmware supports the CONFIRMATION handshake at boot. Apply the same logic during suspend: only send the suspend message and wait for the suspend ack when the firmware is expected to support it. Signed-off-by: Iuliana Prodan <[email protected]> --- Changes since v1: - Moved confirmation check earlier to avoid sending the message when FEATURE_SKIP_FW_CONFIRMATION is set, since RP_MBOX_SUSPEND_SYSTEM is not handled on the remote side. --- drivers/remoteproc/imx_dsp_rproc.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c index 1f3a35756769..d03017d6b214 100644 --- a/drivers/remoteproc/imx_dsp_rproc.c +++ b/drivers/remoteproc/imx_dsp_rproc.c @@ -1251,6 +1251,12 @@ static int imx_dsp_suspend(struct device *dev) goto out; } + /* No fw confirmation expected, so trigger PM runtime suspend */ + if (!(priv->flags & WAIT_FW_CONFIRMATION)) { + dev_dbg(dev, "No FW_CONFIRMATION needed, suspend directly.\n"); + goto out; + } + reinit_completion(&priv->pm_comp); /* Tell DSP that suspend is happening */ -- 2.25.1
