WWAN wakeup from BroadMobi BM818 not working

We need to check that the BroadMobi BM818 modem will wake up the CPU on an incoming call, etc.

Related issue: ModemManager#29

use-cases#75

changed the description

we don't yet offer system suspend, but have it experimentally soon (I guess). Just tested again and an incoming call wakes the system from s3 suspend. see also https://source.puri.sm/Librem5/linux-next/issues/72

btw. calls is opened too, making this complete.

added broadmobi label

changed the description

right now, Birch with a Broadmobi BM818 doesn't wake up by calling it. We're looking into whether better devicetree descriptions can fix this.

(discussion via email too) when I add this change:

--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
@@ -54,6 +54,13 @@
 			linux,code = <KEY_WWAN>;
 		};
 
+		wwan_wake {
+			label = "WWAN_WAKE";
+			gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+			linux,code = <KEY_PHONE>;
+		};
+
 		vol_up {
 			label = "VOL_UP";
 			gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;

suddenly "mmcli -m 1" looks not good. don't know why, but it's ringing at least:

  -------------------------
  General |      dbus path: /org/freedesktop/ModemManager1/Modem/1
  -------------------------
  System  |         device: /sys/devices/platform/soc@0/38200000.usb/xhci-hcd.4.auto/usb1/1-1/1-1.2
          |        drivers: qmi_wwan, option1
          |         plugin: Generic
          |   primary port: cdc-wdm0
          |          ports: ttyUSB0 (qcdm), ttyUSB1 (at), ttyUSB2 (at), ttyUSB3 (at), 
          |                 wwan0 (net), cdc-wdm0 (qmi)
  -------------------------
  Status  | signal quality: 0% (cached)
  -------------------------
  Modes   |      supported: allowed: any; preferred: none
          |        current: allowed: any; preferred: none

when I revert said change, I get registered and signal again...

and in terms of wake up on calling:

• sudo systemctl suspend
• call Birch -> not ringing. not waking up.

The not looking so good seems to be ModemManager#14, which is intermittent. I doubt your change caused this.

thanks! indeed this is unrelated. I got registered normally after a reboot or two. In that situation, still, when suspended Birch doesn't wake up or even ring (on the calling side).

added suspend label

changed title from WWAN wakeup to WWAN wakeup from BroadMobi BM818

Maybe we need to adjust the pinmux for this pin. Is the pullup enabled for it ?

according to chapter 8.2.5.226 I added bit 6, so 0xC0 if I get that right, which doesn't change things. Could any config else be wrong here?

@eric.kuzmenko anything that comes to your mind regarding the 4g-wake pin?

There is already an external pull-up on 4G_WAKE net, so the internal pull-up does not need to be enabled.

GPIO3_IO15 should be pinmuxed as 0x180 or 0x80.

If for some reason that does not work then you can try enabling the internal pull-up by setting it to 0x1C0 or 0xC0, but if it works without the pull-up enabled then you should leave PUE set to 0 (0x180 or 0x80).

thanks. I still couldn't test this successfully with those settings.

Just to make sure it's actually toggling, I scoped the wake pin while the display was off using this test point on the BM818:

Here's the pin toggling while receiving a phone call (while the display was turned off):

The BM818-A1 module I tested with has this firmware version on it:

+BMSWVER: M100E_1.0.0_190328,BMC_M100E_1ACD_B325_V1.0.0.0_20190329,M100E_1.0.0_190328

Here's the kernel I'm using:

purism@pureos:~$ uname -a
Linux pureos 5.3.0-librem5-g25cbd8e9f #1 SMP PREEMPT Mon Jan 20 11:02:17 PST 2020 aarch64 GNU/Linux

I get a 1 second LOW pulse every 5 seconds (every ring) when I receive a call:

I get a 1.65 second LOW pulse when I receive an SMS:

oh thanks for doing these tests so quickly Eric! that helps

added needswork label

changed title from WWAN wakeup from BroadMobi BM818 to WWAN wakeup from BroadMobi BM818 not working

changed the description

mentioned in issue #72 (closed)

FWIW, when calling Birch while system running, I get:

E: 0.000001 0001 00a9 0001	# EV_KEY / KEY_PHONE            1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 1.003997 0001 00a9 0000	# EV_KEY / KEY_PHONE            0
E: 1.003997 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +1003ms
E: 4.999978 0001 00a9 0001	# EV_KEY / KEY_PHONE            1
E: 4.999978 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +3996ms
E: 5.996002 0001 00a9 0000	# EV_KEY / KEY_PHONE            0
E: 5.996002 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +997ms
E: 10.000534 0001 00a9 0001	# EV_KEY / KEY_PHONE            1
E: 10.000534 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +4004ms
E: 10.996518 0001 00a9 0000	# EV_KEY / KEY_PHONE            0
E: 10.996518 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +996ms

so that actually should work... I'll re-test wakeup from suspend later.

nope. no resume when calling when suspended. resume by key-press works. phone rings when awake.

My testing on 5.6-rc4 with mainline ATF seems to suggest that BM818 gets powered off in suspend - if that's the case, it may explain why it doesn't wake up the CPU ;) @martin.kepplinger do you get a dial tone when calling the suspended phone, or does it behave like the called number is unavailable?

nope, it goes to voicemail without dialing (possibly with a strange delay, not sure about that), but you're right. I guess it's the behaviour of a shut down modem.

I wonder if the qmi_wwan_suspend() function in drivers/net/usb/qmi_wwan.c causes shutdown rather than suspend with the BM818.

Does suspend work correctly with the proprietary software provided by BroadMobi?

PS: I probably don't know what I'm talking about, but throwing it out there in case it helps anyone.

It rather sounds like a simple issue of the regulator getting disabled in suspend due to device tree misconfiguration, so the modem just gets its power cut off, which explains why it doesn't react to incoming calls anymore :)

The modem sure stays awake with no issues and sends wakeup notifications even when USB is completely disabled, so that part works. The SoCs waking up from such signal also works fine on the devkit. We just need to make sure the kernel doesn't cut the power from the modem when the CPU is going into suspend.

(also, keep in mind that this isn't a high urgency issue since we're not planning to use CPU suspend anytime soon)

mentioned in issue user-personas#14

couldn't this just be that a "low power mode": https://source.puri.sm/Librem5/linux-next/-/issues/20 needs to be enable in order for the modem to do wakeups?

@martin.kepplinger Last time I've got suspend to work (without DDR scaling), the whole modem was being powered down so it obviously couldn't wake anything up :D I haven't seen any details about low power modes of BM818 in its docs, but in my experience with other modems that's usually achieved by suspending or detaching USB link, so I don't think we have anything special to do there. I have already seen in the past that WWAN_WAKE signal works fine even when the whole USB hub is off, so the modem side should be fine.

mentioned in merge request librem5-base!279 (merged)

I think the one side it that xhci and the devices expect userspace to configure power/wakeup (and so on) in order to allow wakup in the first place.

But then of course the modem has to be able to do so, keeping power. dwc3 config changes may be needed?

We don't need dwc3 at all for the modem to wake the system up from suspend - that's what 4G_WAKE pin is for.

yes but somebody is cutting off power when suspending...

Sure, but that won't be related to USB - you can turn off the whole USB hub and the modem still stays operational.

but the dwc3 port can cut off power from the hub too if it wanted to. who else would do it?

Cutting power from the port does not turn the modem off.

What's the state of 4G_PWR_EN pin during suspend?

There's also 4G_W_DISABLE to consider, although I bet that's not it because I've never seen it actually working :P

Judging from the schematics I don't think there's any other way to programmatically cut the power from the modem.

Haven't tested, but it seems like all we need may be retain-state-suspended in wwan-en block in the device tree.

just for reference: power/wakeup is not needed in sysfs for the modem, at least as long we use the leds and gpio-keys description for the modem.

mentioned in merge request !510 (merged)

while I think this would be a workaround, I think that the following addition must result in the "key" being "pressed" on an incoming call (when the phone is not suspended, for testing), right?

--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -40,6 +40,16 @@ gpio-keys {
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_keys>;
 
+               wwan_wake {
+                       label = "WWAN_WAKE";
+                       gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
+                       interrupt-parent = <&gpio3>;
+                       interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+                       linux,code = <KEY_PHONE>;
+                       wakeup-source;
+               };
+
+
                vol-down {
                        label = "VOL_DOWN";
                        gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;

it is not on my evergreen I test

It sure used to work with:

		wwan-wake {
			label = "WWAN_WAKE";
			gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_PHONE>;
			wakeup-source;
		};

KEY_PHONE was getting "pressed" periodically while the phone was ringing. It also was constantly pressed while the modem was off (which is why we removed it from dts).

I had seen this work on Birch, as found in this issue above, too. I tested without interrupt description as well. it doesn't get "pressed" for me. But this is something that anybody could test on our kernels.

that's obvious since the modem behaves the same on this line, but it neither works for sms.

Can't spot any difference between Birch and Evergreen in the schematics for this line.

and just to make it clear, VOL_UP/DOWN works as gpio key (evemu-record) and wakes up the system if I configure it as wakeup source, like the 4g_wake line above.

Does KEY_PHONE get pressed when you turn the modem off via the killswitch?

yes! what does that mean?

the signal goes to low in this case? so the modem doesn't deliver the wowwan signal at all?

Seems so. This may be a matter of configuration, I'll check the BM818 docs.

cool. could you link to those if you have them at hand? thanks.

https://cloud.puri.sm/s/3RBWSCmYZxeNPbP

hm. tried to configure the pullup when describing the pin as 0x01C0 but doesn't change anything. Quickly grepping for a few words in the AT command docs doesn't give me anything.

SMS was supposed to issue an short press (20 ms pulse) and calls a long press (120 ms ) IIRC.

mentioned in issue OS-issues#237

tested https://source.puri.sm/martin.kepplinger/linux-next/-/commits/5.16-rc4/librem5__integration_byzantium_suspend successfully on Dogwood. suspends, incoming call wakes up the system and opens Calls as expected.

Looks like we indeed have different modems by Broadmobi. Thanks @sebastian.krzyszkowiak for testing so much too!

Is it different modems or just different firmware ?

Are those EU modems or NA modems ?

Both my (EU) modems report:

+BMSWVER: M100E_1.0.0_190426,BMC_M100E_1BAD_3117_V1.0.0.0_20190426,M100E_1.0.0_190910

The one that was shipped with Birch sends WOWWAN signals, the one that was shipped with Evergreen does not.

Evergreen that does not have WOWWAN: +BMSWVER: M100E_1.0.0_190426,BMC_M100E_1BAD_3117_V1.0.0.0_20190426,M100E_1.0.0_190910

Dogwood that does receive from WOWWAN:

echo 'AT+BMSWVER' | sudo ./atinout - /dev/ttyUSB1 -

+BMSWVER: M100E_1.0.0_190426,BMC_M100E_1BAD_3117_V1.0.0.0_20190426,M100E_1.0.0_190910

so the same as well. EU modems (I guess).

My current "plan" is to communicate that (together with Sebastian) to Nicole and swap the "good" modem to an Evergreen where I do more testing than on Dogwood.

left: newer modem from Evergreen; right: older modem from Dogwood.

For the reference, I haven't checked the back side of the cards yet, but from the front side both modems I swapped (one working, one not working) look like the one on the left on your photo ("MCode" instead of "Model", slightly smaller sticker). Serial number difference between them is only 119, and both start with 54100200.

I also have two more modems here - one of them looks like the one on the right and has a serial number that starts with 34100190, the other looks like the one on the left as well and starts with 54100100. The 34100190 one does send WOWWAN, the other one I still have to check.

and for completeness: I can confirm that the old modem from Dogwood also sets WOWWAN / 4G_WAKE properly in my Evergreen. this enables to test suspend / resume in the real world a bit for me.

OK, so I have two modems that work and two that don't.

mentioned in merge request librem5-base!285 (merged)

This FW version fixes the WWAN drive strength and the wake from suspend

https://source.puri.sm/Librem5/firmware-bm818-nonfree/-/commit/26cb6e6635792d21ddd43c2d34a2988a11a22b2a

that's kind of huge! Thanks a lot for this! I'll have to test that soon

closed