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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
