ModemManager AT & QMI

[Aleksander Morgado]

Hey!

>
> I am a developer working on a board with a Quectel Modem, and I am in charge of replacing our old abstraction layer with ModemManager to communicate with this modem.
>
> I have been playing with ModemManager for a few days to be familiar with it. I have read the documentation and I have been reading also the source code to better understand how it works.
>
> However, a few fundamental questions remain for me, and I hope some people here may give me some clue.
>
> First of all, when I list the modems found by MM, it returns not one, but two modems:
>
> # mmcli -L
>     /org/freedesktop/ModemManager1/Modem/1 [Quectel] SG520TM
>     /org/freedesktop/ModemManager1/Modem/0 [Quectel] SG520TM
>
> One of them is linked to tty USB port and communicates only with AT commands (ttyUSBx), the other one is linked to the PCIe port and communicates only with QMI (wwan0qmi0).
> I do not have a wwan0at0 driver. The only way to have AT commands is through the ttyUSBx port.
>
> It looks like I have two separate modems, whereas I have only one physical modem, connected to the board with two physical ports (usb & pcie).
>

Yep, that is indeed possible, especially in custom boards. Also, some
manufacturers may expect you to upgrade firmware only via USB while
managing the modem via PCI and things like that.

> The diagrams here suggest that MM can have single modems with more than one protocol, but on the same physical port:
> https://modemmanager.org/docs/modemmanager/wwan-device-types/
>
> Is it possible to have MM create only one modem using two different physical ports (ttyUSBx on USB & wwan0qmi0 on PCIe), in order to have AT & QMI simultaneously?
>
> If not, does it mean that in order to have one modem with AT & QMI, I would need to have a working wwan0at0 driver?
>

You can have one single modem with all the ports in the two different
buses by making sure all the ports have the same ID_MM_PHYSDEV_UID
tag. See https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/ModemManager-Common-udev-tags.html#ID-MM-PHYSDEV-UID:CAPS
And also https://sigquit.wordpress.com/2016/10/06/naming-devices-in-modemmanager/

If you apply that tag to all the ports, e.g. using the DEVPATH of each
port for example, and use the same uid in all (e.g. "MyModem") then
ModemManager will bind all ports in the same modem object. Plus, you
could do "mmcli -m MyModem" as well :)

Of course, you need to ensure that the DEVPATH of your rules doesn't
change. You can assume the DEVPATH of a port in USB or PCI won't
change as long as the hardware layout is the same. A corollary of this
would be that the DEVPATH for the ports in different board units with
the same hardware layout (same board type) won't change either.

>
> My second question is about the cache handling.
> I could see that MM may use cached AT results, meaning that your plugin can have the result of an AT command without actually sending it (with the allow_cached parameter).
> This is a great feature, and experience showed us that it improves dramatically your application latencies.

Please note this applies *exclusively* to commands that are known to
never change, mostly the "test" commands like e.g. "AT+CGDCONT=?" or
"AT+CGACT=?". This caching feature doesn't make sense for commands
that include state values in the response like e.g. "AT+CGDCONT?" or
"AT+CGACT?".

>
> Are QMI or Dbus requests cached as well?
>

No, none of them. There are some commands which could be cached (e.g.
those querying static info from the modem like supported services),
but it's probably not very useful.

-- 
Aleksander