Skip to content

[workday endurence enablement] lower the power consumption during modem standby (phone suspended)

If we assume, as a generous rough estimate, that the BM818 modem could currently actually remain in standby, i.e. only listening to a single LTE tower (not moving), for 24 hours until the full battery is drained, and that we are getting 3800mAh out of the 4500mAh battery, then the modemphones's power consumption during standby still seems to clearly exceed 150mA!

3800/24 mAh/h ~ 158.3mA [ or 585,7mW at the nominal 3,7V ]

However:

  1. Where does that consumption actually occur? Does the standby consumption maybe still include a component that can be turned off? e.g. some usb hub/charger chips still powered? Has somebody measured the actual current drawn only by the modem?
  2. Is that really already the lowest passive network standby state of the BM818 modem? Would it need special commands to let it enter deeper standby modes? e.g. turning off the qmi/serial/usb interfaces also on the modem side ?

Todo items collected from the discussion below:

"L5 workday endurance enablement"

(target is lowering the 600mW of power cunsumption during suspend to 320mW)

Hardware

  • Go through the schematics of peripherals and document component's suspended-activity consumption tests [mesure, cut, mesure, re-solder(possibly to switched/unswitched power as appropriate)] on https://developer.puri.sm/Librem5/. Checking the consumption delta of each component one by one, to arrive at sortable list of possible power savings and documented hardware mods (for example, re-routing mods using flying wires before/behind switches, or connecting some sleep/wake signal modem pin to some interrupt capable SoC GPIO.)

    SoC infos in

    https://community.nxp.com/t5/i-MX-Processors/i-MX8MQ-LPDDR4-deep-sleep-mode/m-p/924828

Software

  • Evaluate disabling unused parts of the RAM during suspend. (Half of the DRAM consumption is estimated to be around 150mW. If the amount of used memory is low enough, it may even become viable to hibernate to eMMC or sdcard and disable the RAM altogether, cutting out its entire 300mW from the suspend consumption.) A first test of the consumption saving could be to enable only parts of the RAM on boot.

    https://lwn.net/Articles/446493/ Memory power management

    https://www.kernel.org/doc/html/latest/admin-guide/mm/memory-hotplug.html

    https://elinux.org/images/f/f3/Lf_elc12_pallardy.pdf PASR Framework Presentation

    https://lwn.net/Articles/479886/ PASR: Partial Array Self-Refresh Framework (adds runtime dynamic power saving, does it also allow discarding RAM in suspend?)

  • Evaluate and enable an alternative modem with sleep mode support as reference, e.g. the global, dual-sim EM12-G. (It can reduce the modem consumption during phone suspend by over 130mW.) (Also present a hardware mod to wire up the hidden SIM2 tray of the L5 :-)

  • For modem related diagnostics, consumption comparison, and power saving workarounds on stock BM818 hardware, get the already booting modem distro in a min. usable shape to run on the BM818 (https://github.com/the-modem-distro/pinephone_modem_sdk/issues/175). If the saving is large enough [or if it is the global usb chip suspend which breaks sdcard write access after resume (linux#484)], explore allowing the complete shutdown and re-init of the modem's usb connection, so all usb and sdcard hardware can be turned off completely during suspend. And allowing the modem to also sleep with usb off instead of suspended.

    One possibility could be making the modems' serial AT interface TTY devices available to the SoC over usb networking. [While on the modem, starting the service with a telnet server/socat/...?, and starting it through the 'screen' or rather the lighter-weight 'screenie' multiplexer. And on the SoC OS, using socat to create serial TTYs devices (http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt) where socat uses telnet and screenie to (re)connect (via its 'EXEC:' destination) to the modem, creating a new or reconnecting to an existing data link. And then using that connection in having the OS freeze/store and re-init the modem connection during resume, in order to succeed in picking up incoming calls or data (without completely resetting the modem during it's re-init).]

Edited by inx