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... Regards, Bjorn
