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).

This patchset is to make the 2nd suspend message could suspend linux
again.

So why SCMI fireware couldn't block the 2nd suspend message from being
sent to Linux agent? Per checking with our SCMI firmware owner:
The SM(System Manager) does not know exactly when Linux is in suspend.
There are no handshakes that clearly tell the SM this. The flow should
be, if in suspend and you send a suspend (or graceful reset/power off)
it will wake and then do the request action

Move information could be found in patch 2 commit log

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (2):
      firmware: arm_scmi: bus: Add pm ops
      firmware: arm_scmi: power_control: Set SCMI_SYSPOWER_IDLE in pm resume

 drivers/firmware/arm_scmi/bus.c                | 45 ++++++++++++++++++++++++++
 drivers/firmware/arm_scmi/scmi_power_control.c | 24 +++++++++++---
 2 files changed, 64 insertions(+), 5 deletions(-)
---
base-commit: 4325743c7e209ae7845293679a4de94b969f2bef
change-id: 20250620-scmi-pm-8f6170769230

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

On Fri, Jun 20, 2025 at 11:37:12AM +0800, Peng Fan (OSS) wrote:
> 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).
> 

Hi,

> 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).
> 
> This patchset is to make the 2nd suspend message could suspend linux
> again.
> 
> So why SCMI fireware couldn't block the 2nd suspend message from being
> sent to Linux agent? Per checking with our SCMI firmware owner:
> The SM(System Manager) does not know exactly when Linux is in suspend.
> There are no handshakes that clearly tell the SM this. The flow should
> be, if in suspend and you send a suspend (or graceful reset/power off)
> it will wake and then do the request action

Shouldn't the suspended-state of the agent be known to the SCNI server
since:

  A. the SCMI/server has somehow requested a suspend itself sending
     previously a SUSPEND SysPower notification (maybe to fulfill a
     Mnagement entity request)

OR

  B. Linux suspended itself by issuing a PSCI_SUSPEND call to EL3 which
     in turn should have notified the SCMI server os such request by
     issuing a SYSTEM_POWER_STATE_SET to the SCMI server

As in 3.4.1

"On application processors, a PSCI implementation. The PSCI implementation
fulfills OSPM calls to SYSTEM_OFF, SYSTEM_SUSPEND, SYSTEM_RESET and
SYSTEM_RESET2 functions. To do so, the PSCI implementation uses the SCMI
protocol to request system power down or reset transitions."


So how can the SCMI server be NOT aware of the current state of the OSPM
and send a second unneeded message ?

Also addressing Chuck reply later in this thread...

...why if the system is suspended, for whatever reason, and receives a
graceful shutdown notification it does NOT wakeup (due to the
notification received) and then shuwdown to fulfill the request just
received ? Is this the bug ? The wakeup-nortificatin is NOT processed
properly by the driver after it has been woke up ? 

Thanks,
Cristian