Continuing the discussion from It's a burning phone:
Anyone aware of any rumors or updates on suspend for Librem 5? My understanding is that this will help significantly for standby battery life of the L5.
Perhaps there is a gitlab issue already?
It seems like it has been several months since I have heard of any change. I remember that Purism clarified that they would focus on the “active” battery life first, so maybe there has been no further work done on this?
Many details here:
You should also see: https://source.puri.sm/Librem5/linux-next/-/issues/12
Basically the Synopsys USB 3.0 (dwc3) used by the I.MX 8M processor doesn’t wake up from suspend correctly.
Exactly… this is 1 year ago. 1 year is a long time. and by the way…, who cares whether USB returns to a working state? The issue here is to save lots of battery and lots of heating. If I need the USB, L5 is already a winner in how fast it reboots.
If people have a working suspend with problems just with the USB this must be merged. It is more important than USB (since you can always reboot and disable suspend if needed).
I was under the impression that some of the internal components use the usb bus. Such as the modem and wifi cards. Could be wrong though.
I agree though, the biggest issue I have with the phone is low suspend battery life.
My understanding: Modem - yes; WiFi - no
So if you want an incoming call to wake the phone (many people would! @antonis) then you want a USB device to be able to wake the phone. I’m not really across the internals though. There may be multiple USB buses, with different behaviours.
I guess you are right. Looks like Purism are in for the long run mainlining as much as possible. It takes longer but probably worth it.
The i.MX 8M Quad only has 2 USB buses, which can both run at either USB 2.0 or 3.0. One bus is for the USB-C port and the test points, and it is using USB 3.0. The other bus is for the microSD card and cellular modem and is using USB 2.0. The USB is provided by Synopsys and it uses the dwc3 driver.
It looks like Purism can work around this problem by unloading the USB driver before suspend with ` rmmod dwc3 and then reenabling it with modprobe -l dwc3 after resume. However, the bigger problem is that they still haven’t figured out how to suspend the BM818 cellular modem and still haven’t figured out how to make the RS9116 WiFi and BM818 modem to wake up the system when a phone call is received (see the links in the FAQ). Judging from the comments in the bug reports, it doesn’t look like these issues have received a lot of attention from the dev team. It’s hard for me to judge how quickly they can be solved, but they don’t look like easy issues to me.
That’s because that’s not the problem at all, just a matter of correct regulator configuration to not turn the modem off during suspend. The thing that would have to be done first is creating a branch of the ATF where both suspend and devfreq could work at the same time and this is the main thing blocking suspend to ram at the moment. With that in place there are several smaller issues like the dwc3 thing that will have to be debugged one by one.
ATF?