Howto - automatically recover your modem and mobile data after deep sleep

[a-wai]

Basically, it's just a userspace re-implementation of megi's power management driver, with an mguard-like feature for modem recovery (force disconnect/reconnect the modem if it doesn't come back online after suspend).

This also means it can be used with any kernel, except megi's as it conflicts with its own modem management driver.

[scholbert]

Basically, it's just a userspace re-implementation of megi's power management driver, with an mguard-like feature for modem recovery (force disconnect/reconnect the modem if it doesn't come back online after suspend).

This also means it can be used with any kernel, except megi's as it conflicts with its own modem management driver.

Hi a-wai,

many progress had been made in the last weeks. Great work!!!
Though i kept upgrading from 1113 image, i guess i will do a clean flash to my device again with the latest 1215 image.
BTW, i'm running Mobian on V1.2b mainboard hardware.

Let me describe what i observed concerning modem behaviour.
I kept my device in flight mode. After power up i am directly prompted to enter SIM pin.
Everything fine, modem usb ports are all there. Modem settings are reachable through UI. Then let the device go directly into sleep -> enter crust mode.

After a while power up, by the phone by pressing the power button. Modem had completely gone.
Checking dmesg gives there'd been no usb enumeration/no ports at all.

Then again some deep sleep, tried again... throwing some dice and the modem was there again. So it seems not to be a static behaviour.
Anyway most of the time it's gone.

I guess i'll have to dig a little deeper into the code to understand the wake up procedure, when the phone tries to come back to live...
BTW is the DTR-Pin triggered to try and wake up the modem as well?

There'd been some rumours, it's all caused by modems firmware... maybe i'll have to collect some informations on this.

What do you think about the possibility that the usb enumeration got stuck/is not retriggered on the modems side?
The A64 hub would have trouble to get the ports back then.
What if we would be able to switch VBUS of the modem seperately?
I know that this is not possible with the actual hardware, but just in case...

Anyway, hopefully this issue could be solved by software, because i think power management and modem handling is very essential for a mobile.

Best regards,
scholbert

[HLing]

i don't know if this is where I post my issue: This has happened before, where my phone rings continuously, but unresponsive to attempts to pick up. Yesterday my phone rang when I was already speaking on the phone with my mom. I see the option to pick up, so i pressed it. My mom is still on the line. I can hear her. I couldn't answer the 2nd incoming call. My mom hangs up. Still I am unable to answer the ringing phone. Had to do a hard power off. Is this the state of things for now ? Or was there something I could have done to answer the 2nd call?

[scholbert]

Hi,
short update here...

I found out that if the modem does not come back and refuses to enumerate after wake up, i'll have to restart the eg25-manager service.

Code:

systemctl restart eg25-manager

... but i guess what exactely happens here, is that the modem got a forced reset.
So i think this was discussed already many times.

Anyway the interface comes back this way... SIM-Pin has to be entered then.
Maybe we could tweak the service a little bit to restart automatically...

I thought a lot already about the real cause for this issue.
Maybe some part of the USB connection is left in an undefined state during sleep.
Could also be related to the handover while entering crust, or after leaving crust.

So i wonder if we could do some measurements to dig a little deeper...
Would be really interesting as well if it's really the modem part causing this... maybe the host controller of A64 has some quirks too (suspend/resume related).

It would be so awesome to get this fixed!

BTW did anyone already dig deep in the modem setup configuration?
Maybe there's a little tweak to be done...

EDIT:
Had a short glimpse at megous kernel driver:

Code:

    /* enable the modem to go to sleep when DTR is low */
    ret = mpwr_serdev_at_cmd(mpwr, "AT+QSCLK=1", 2000);
        if (ret)
        dev_err(mpwr->dev, "Modem will probably not sleep!\n");

... and this is what is done in eg25-manger during init:

Code:

append_at_command(manager, "QSCLK", NULL, "1", NULL);

So my guess is that we are already prepared for DTR then...
I don't want to confuse people here... but i just had a closer look at the EG25 AT-Manual for the sequence to enter sleep... AT+QSCLK=1 is an essential part here.

EDIT2:
In the meantime i read the discussion/reports in eg25-manager issue tracker... it seems that some very skilled persons are diggin' deep.
If modem issue is not caused by a hardware flaw, i'm sure they will solve it.

Regards,
scholbert