Faster resume probing

[Aleksander Morgado]

Hey,

> > > I think we need to understand why, in the case of suspend/resume
> > > cycle and using only QMI, we're not receiving and processing the WMS
> > > indications properly:
> > > * As said above, does the host even awake when the SMS arrives and
> > > we're using QMI?
> > > * Is it any different (host awaking) when using AT?
> > > * Or is it that when using AT the URCs are queued in the modem and
> > > once the host is awake later on we end up reading them correctly? And
> > > if so, why is this not happening in the same way with QMI?
> >
> > * The host is still in it's resuming phase when the QMI indication
> > comes in.
> > * AT URCs are cached by the modem until the host is fully resumed. This
> > is controlled by the eg25-manager.
> >
>
> Had to look that up :) So, that EG25Manager is sending
> AT+QCFG="urc/cache",1 to enable the URC cache before when suspending,
> and disables that upon resume.
>
> When you say the QMI indication comes in while we're resuming and not
> fully ready, does that mean those USB packets are lost and never read?
> or not read properly because the USB layer isn't ready to read them?
> Or that they're not even sent to the host by the modem?
>

Thinking about how to handle this in the most generic way, we could
improve ModemManager so that if we know a modem is kept powered during
a suspend/resume cycle, we reload the full SMS list on resume, just
assuming there may be indications that we may have lost.

Although that is just one thing to do really; if we cannot rely on the
indications to be queued for us to read, we would also need to reload
ALL the modem state, not just the full SMS list, including
registration state, location info, connection state... that is kind of
what we already do when you enable the suspend/resume support; we
fully re-probe the modem not just because it's easier for us, but
because we make sure MM daemon and the modem are in sync with all
state values. That is something you cannot fully guarantee if you
don't enable the suspend/resume info, or maybe yes because the host
anyway awakes on certain events. This is very very setup-specific.

I think our first target if we want to start supporting awake modems
while host is suspended should be to maintain the connectivity up and
skip the probing phase on resume. That may be quite reasonable to do
without major modifications in the codebase. My only concern is how to
know beforehand that the modem will be awake during suspension, a
configuration file is the only thing I can think of right now.

-- 
Aleksander
https://aleksander.es