Faster resume probing

[Dylan Van Assche]

Hi,

> 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?

The URC cache thingy is documented in [3] and is a Quectel extension.

Well, I'm not sure, but the behavior is like this:

- Modem has an incoming call or text, wakes up the host
- Host starts to resume, modem directly sent the QMI indication
- The host is fully resumed, ModemManager in the userspace is ready to
receive 
- The QMI indication is not seen by ModemManager

I suspect that QMI indication is received by the modem (as this is the
case when the host is awake), but that the userspace isn't resumed yet.
The same happened before with URCs over ATs when the URC cache wasn't
used.

My hacky workaround [1] I have running here locally, is slightly
different than my MR where I fully falling back to AT for messaging.
My hacky workaround has hardcoded that the URCs are always enabled 
and for the rest QMI is used. That works fine as well. This way, MM is
notified through AT URCs but processes the messaging through QMI.

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

True, in my setup-specific case, I just need to tell the modem somehow:
look, I'm suspended, wait for cache anything until I tell you that I'm
ready.
The hardware design guide[2] indicates that AP_READY pin can be used to
signal the modem that the host is asleep. However, the AT documentation
is lacky [3], we never got this feature to work on the Quectel
firmware, and some hardware revisions of the PinePhone haven't
connected this pin in the hardware.
The Power Management guide [4] also speaks about AP_READY.
However, this feature is not supported for QMI, so relying on AT URCs
seems to be the only way for this modem.

Or is there a known way to let the modem hold up QMI indications?
AT commands are widely documented, but QMI is one big proprietary black
box to me.

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

I think we can just avoid the configuration file by specifying a new
CLI argument: `--always-on` (or something). If that's enabled, the
suspend/resume hooks are skipped and AT URCs are used instead of QMI
indications for detecting calls and text messages?
This would be in the first step of course. As soon as that work and
more always on modems are getting in use, we can move to a
configuration?

[1]
https://gitlab.freedesktop.org/dylanvanassche/ModemManager/-/commit/149cbe5b22b6440d59225e00bf36c19a9009b8d7
[2]
https://www.quectel.com/UploadImage/Downlad/Quectel_EG25-G_Hardware_Design_V1.2.pdf
[3]
https://www.quectel.com/UploadImage/Downlad/Quectel_EC25&EC21_AT_Commands_Manual_V1.3.pdf
[4]
https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG9x_Power_Management_Application_Note_V1.0.pdf.

Kind regards,
Dylan Van Assche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20210201/fa50b0b5/attachment.sig>