Hi, Thanks for taking the time to test the system. On 1/7/25 12:00, André Draszik wrote: > Hi Thomas, > > Thanks for your patch! > > On Thu, 2025-01-02 at 12:15 +0100, Thomas Antoine via B4 Relay wrote: >> From: Thomas Antoine <t.antoine@xxxxxxxxxxxx> >> >> The interface of the Maxim max77759 fuel gauge has a lot of common with the >> Maxim max1720x. The major difference is the lack of non-volatile memory >> slave address. No slave is available at address 0xb of the i2c bus, which >> is coherent with the following driver from google: line 5836 disables >> non-volatile memory for m5 gauge. >> >> https://android.googlesource.com/kernel/google-modules/bms/+/1a68c36bef474573cc8629cc1d121eb6a81ab68c/max1720x_battery.c >> >> Other differences include the lack of V_BATT register to read the battery >> level and a difference in the way to identify the chip (the same register >> is used but not the same mask). > > It also seems the reported POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN is > quite a bit off - on my Pixel 6, it reports ca. 1131mAh, but the downstream > stack reports a more reasonable 4524mAh. Interestingly, this is an exact > multiple of four. > > POWER_SUPPLY_PROP_CHARGE_FULL is off in a similar way, and I suspect that > related properties like charge_avg, time_to_empty, time_to_full are > reported incorrectly as well. Indeed, now that I check the code, the current computation is wrong. In the downstream kernel, reg_to_capacity_uah is used to translate the register value. In the end, it computes the value as follows: div_s64((s64) val * 500000, rsense) * lsb; Link: https://android.googlesource.com/kernel/google-modules/bms/+/refs/heads/android-gs-raviole-5.10-android15/max1720x_battery.h#36 whereas the mainline driver does val * 500. Based on what I saw, lsb should be 1 to 2 based on the value of the register MAX_M5_TASKPERIOD. Basically, if lsb is 1 and given the default rsense of the mainline driver, the two functions will return the same.
