Re: [PATCH 2/2] firmware: arm_scmi: power_control: Set SCMI_SYSPOWER_IDLE in pm resume

[Dhruva Gole <d-gole@ti.com>]

On Jun 20, 2025 at 11:37:14 +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> When two consecutive suspend message send to the Linux agent, Linux will
> suspend and wake up. The exepcted behaviour should be suspend, wake up

I am first trying to gather more context of the issue at hand here,
Why and who is sending 2 consecutive suspend messages to Linux?

Just quoting the cover letter:

> When testing on i.MX95, two consecutive suspend message send to the Linux
> agent, Linux will suspend(by the 1st suspend message) and wake up(by the
> 2nd suspend message).
> 
> The ARM SCMI spec does not allow for filtering of which messages an agent
> wants to get on the system power protocol. To i.MX95, as we use mailbox
> to receive message, and the mailbox supports wake up, so linux will also
> get a repeated suspend message. This will cause Linux to wake (and should
> then go back into suspend).

When you say mailbox supports wake up you mean the mailbox IP in your
SoC actually gets some sort of wake interrupt that triggers a wakeup?
Is this wakeup sent to the SM then to be processed further and trigger a
linux wakeup?

<or> the mailbox directly wakes up linux, ie. triggers a resume flow but
then you are saying it was an unintentional wakeup so you want to
suspend linux again? This just seems like the wakeup routing is
incorrect and the system is going through a who resume and then suspend
cycle without a good reason?

Why and when in this flow is linux ending up with a duplicate suspend message is
something I still don't follow.

Could you point us to any flow diagrams or software sequences that we
could review?

> and suspend again.
> 
> The ARM SCMI spec does not allow for filtering of which messages an agent
> wants to get on the system power protocol. To i.MX95, as we use mailbox
> to receive message, and the mailbox supports wake up, so linux will also
> get a repeated suspend message. This will cause Linux to wake (and should
> then go back into suspend).
> 
> In current driver, the state is set back to SCMI_SYSPOWER_IDLE after
> pm_suspend finish, however the workqueue could be scheduled after
> thaw_kernel_threads. So the 2nd suspend will return early with
> "Transition already in progress...ignore", and leave Linux in wakeup
> state.
> 
> So set SCMI_SYSPOWER_IDLE in device resume phase before workqueue
> is scheduled to make the 2nd suspend message could suspend Linux again.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  drivers/firmware/arm_scmi/scmi_power_control.c | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
[...]

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated