[PATCH 2/4] dt-bindings: power: supply: add max77759-fg flavor and don't require nvme address

[Thomas Antoine]

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 at uclouvain.be>
>>>>
>>>> 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