Faster resume probing

[Dylan Van Assche]

Hi!

> > Thanks to the logs of ModemManager, I could identify several places
> > where we lose some time during the resume sequence of a
suspend/resume
> > cycle:
> >
> > 1. ModemManager waits a fixed amount of time to make sure that all
> > ports of a modem show up using udev, losing ~1.5s
>
> It's a bit more complex than that; but yes, at least 1.5s waiting is
> the minimum IIRC. This is because there are systems where the ports
> are notified slower (e.g. openwrt using mmcli --report-kernel-event 
> is slower than a standard distro using udev). The refactoring done in
> this area in the past years has always been to try to increase that
> minimum time, never to reduce it, basically because we rely on how
> fast we're notified of the ports of a given modem.

I tried to play around with these values but things break when you do
that :P It's very complex to reduce it without breaking anything.

> > 2. The EG25-G modem contains ~20 carrier configs which are read 
> > one-by-one by ModemManager during the initialization phase which 
> > takes ~1.5s
>
> This could be probably improved. There carrier config loading and
> checking is required in some modules where we support automatic
> carrier config selection, but it's optional in all the others. It may
> be possible to reduce this time when the feature is not required.

Ah I didn't know this was optional... On the PinePhone we have carrier
configs for VoLTE and it is configured to let the modem automatically
select the right carrier config for that. Or is this another kind of
carrier config?

> > 3. Order of service initialization: the voice interface for 
> > handling calls is initialized at the very end, while location, 
> > time, etc. are initialized first. ~500ms
>
> This one is tricky, because ideally we would completely ignore all
> indications received, of every interface, until the whole
> initialization has finished (so it wouldn't matter in which order 
> it's initialized). Also, the voice interface indication handlers are
> enabled during initialization basically for emergency calls, as the
> PIN may be locked at that time. For the case of no SIM-PIN lock, your
> numbers are probably fine, but you'd need to consider also the
> enabling phase, not just the initialization phase.

True! I disabled the PIN on my SIM so you're probably right...

> I think we're probably looking at this issue from the wrong angle.
> Instead of improving the device probing and initialization, which is
> done on device detection and (currently) also after suspend-resuming;
> we should probably avoid triggering the full device re-probe on
> resume. The device reprobe on resume was setup in order to cope with
> devices that would get power-cycled during the sequence, or that 
> would at least lose all the state during the suspend-resume (e.g. 
> they would also be suspended). In your case, and in others (see
>
https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/31
> and especifically
>
https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/31/diffs?commit_id=5d5fc08b0704513c4c6d8f3e18d07476e53757a9
),
> the modem stays fully awake and operational while the host is
> suspended.

When I disable the resume and suspend hooks of ModemManager, incoming
calls still work, but text messages aren't detected.
The modem wakes up the host, but ModemManager doesn't pull the text
messages from the modem. If you restart ModemManager, the text messages
are retrieved.