For adventurous folks who wish to build the kernel, a module, and flash the LPC firmware, there is now a prototype kernel driver that will return the battery voltage, current, percentage, and charging state as known by the LPC.
the firmware and module (reform2-lpc-driver):
the device tree changes are visible in a merge request for the kernel:
The LPC firmware has only been tested on my device, but I am confident that it will not lock up and crash the LPC, it does a fake kinda spi that is non-blocking.
The driver can be massively improved to create proper entries for standard hardware devices so that existing desktop utilities find the battery automatically. As-is though, adding an entry so that sway-waybar can show the battery state is quick.
no problem!
I’ve added power_supply driver class support based on the properties currently available in the lpc. existing power apps now recognize the battery and its state, after the lpc calibrates itself through a full charge cycle.
An interface to poll the cell voltage and lpc charge state is also present, though unused in the power_supply sys class.
native-path: 8xlifepo4
power supply: yes
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
warning-level: none
energy: 48.9942 Wh
energy-empty: 0 Wh
// -- obv incorrect, result of battery not being calibrated yet
energy-full: 79.9064 Wh
energy-full-design: 51.6258 Wh
energy-rate: 5.39929 W
voltage: 27.219 V
charge-cycles: N/A
percentage: 100%
capacity: 100%
technology: lithium-iron-phosphate
icon-name: 'battery-full-charged-symbolic'
I’m testing this now in my personal Reform. I have built and flashed the LPC firmware, and built the LPC module on Reform itself, which worked fine. I can also load the module.
What is the expected behavior when LPC is still in “???%” mode? When running powerstat, it says Device is not discharging, cannot measure power usage. The battery info on the OLED says 0.247A discharge at the moment, though.
Edit: /sys/class/power_supply is empty for me. Where can I find the info that you pasted above?
Edit: Ah, I’m silly, probably need to update DTS as well
Yeah, the both the LPC and DTS need to be updated.
The lpc firmware sends its guess as to what the percentage is when its uncalibrated over spi. I couldn’t find any battery state that matched “calibrating” in the kernel power supply driver class.
Further confusing matters is that different battery applets poll different properties. The Sway one ignores the percentage capacity property entirely (and does not have code to even read it), preferring to calculate amp hours instead.
I haven’t delved into what KDE or Gnome do, perhaps they respect that property over monitoring mAh consumption.
Looks good so far, I’ve merged the DTB changes into reform-debian-packages already, so installing a new reform kernel image package on a sysimage V3 Reform will already pull those in.
Testing here with KDE’s powerdevil and gnome-power-statistics. Will also put it in waybar, and test for a few days!
Observation: Discharge and Charge events are correctly recognized (plugging/unplugging power), but the system needs almost a minute to realize that this happened. Maybe a very long polling interval?
The driver does no polling or caching. Any access of the device node does an immediate query to the lpc. Sway battery indicator defaults to a minute pool interval iirc, I recall having to change that for its indicator.
