On 8/11/2021 9:55 AM, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-08-10 16:11:10)
On Tue 10 Aug 14:18 CDT 2021, Stephen Boyd wrote:
Quoting Sibi Sankar (2021-08-10 10:24:32)
On 2021-08-09 23:28, Stephen Boyd wrote:
Quoting Deepak Kumar Singh (2021-08-09 04:05:08)
On 8/6/2021 1:10 AM, Stephen Boyd wrote:
Quoting Deepak Kumar Singh (2021-08-05 09:17:33)
Some use cases require SMP2P interrupts to wake up the host
from suspend.
Please elaborate on this point so we understand what sort of scenarios
want to wakeup from suspend.
Once such scenario is where WiFi/modem crashes and notifies crash to
local host through smp2p
if local host is in suspend it should wake up to handle the crash and
reboot the WiFi/modem.
Does anything go wrong if the firmware crashes during suspend and the
local host doesn't handle it until it wakes for some other reason? I'd
like to understand if the crash handling can be delayed/combined with
another wakeup.
If the modem firmware crashes
during suspend, the system comes
out of xo-shutdown and AFAIK stays
there until we handle the interrupt.
So you're saying we waste power if we don't wakeup the AP and leave the
SoC in a shallow low power state? That would be good to have indicated
in the code via a comment and in the commit text so we know that we want
to handle the wakeup by default.
Sounds like in a system without autosleep (or userspace equivalent) it
would be desirable to leave the SoC in this lower state than to wake up
the system handle the crash and then just idle?
But leaving the system in this state will result in you missing your
important phone calls...
Yes I think we should just add a comment to the code and commit text and
move on.
Thanks, updated in patch set V2
