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 _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
