On 12/3/24 11:40, André Draszik wrote: > On Tue, 2024-12-03 at 11:23 +0100, Thomas Antoine wrote: >> On 12/3/24 08:12, André Draszik wrote: >>> On Mon, 2024-12-02 at 14:07 +0100, Thomas Antoine via B4 Relay wrote: >>>> From: Thomas Antoine <t.antoine@xxxxxxxxxxxx> >>>> >>>> As the Maxim max77759 fuel gauge has no non-volatile memory slave address, >>>> make it non-obligatory. Except for this, the max77759 seems to behave the >>>> same as the max1720x. >>> >>> What about the battery characterization tables? Aren't they needed for >>> correct reporting? >> >> I checked some other patches which added fuel gauge and other bindings and I >> couldn't find such characterization table. Can you point me to an example or >> explain what it should contain if there needs one? > > I haven't looked in detail, but there is > > > https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/arch/arm64/boot/dts/google/gs101-oriole-battery.dtsi#13 > https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/arch/arm64/boot/dts/google/gs101-raven-battery.dtsi#13 > > which include > https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/arch/arm64/boot/dts/google/gs101-oriole-battery-data.dtsi > https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/arch/arm64/boot/dts/google/gs101-raven-battery-data.dtsi > respectively > > Both overlay > https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/arch/arm64/boot/dts/google/gs101-raviole-battery.dtsi#177 I looked into it. The probe function launches a delay work max1720x_model_work which will try multiple times to run max1720x_model_load which leads to max_m5_load_gauge_model -> max_m5_update_custom_model This last function writes 0x0059 to 0x62 and 0x00c4 to 0x63 which unlocks the addresses from 0x80 to 0xaf. Those actually contain the model but are usually locked, returning only 0xff. It then writes the model and locks back the register. I tried it and I was indeed able to access this data on my device. The registers contained a model very close to the default-a1-0k fg-model contained in the downstream devicetree. The only diffrence is that all the 0x0100 are replaced with 0x0080. I think those registers are similar to the registers 180h to 1AFh of the max1720x ("ModelGauge m5 Algorithm Model registers" in the datasheet). The fg-params is used to set individual registers like CGAIN or CONFIG2 but from what I see, those are also on the max1720x. If it is indeed the case and that all of those are equivalent to their max1720x counterpart, I think the management of those values should be added in another patch which implements it for both the max1720x (and possibly the max77759) as the mainline driver does not do anything with those values currently. Best, Thomas