Re: [PATCH 1/3] power: supply: add battery driver for netronix ec

Ing. Josua Mayer
2025-12-27T23:37:29Z

Am 27.12.25 um 22:38 schrieb Andreas Kemnade:
> On Sat, 27 Dec 2025 17:28:13 +0100
> Josua Mayer <josua.mayer@jm0.eu> wrote:
>
>> Implement a simple battery driver for monitoring voltage with the
>> netronix embedded controller found in certain ebook readers.
>>
>> Signed-off-by: Josua Mayer <josua.mayer@jm0.eu>
>
> This also produces a value somehow depending on battery voltage
> on the Tolino vision.
Good!

> [...]
>> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
>> index 08c68de0f01bc..d5059b8862aa8 100644
>> --- a/drivers/mfd/ntxec.c
>> +++ b/drivers/mfd/ntxec.c
>> @@ -139,6 +139,7 @@ static const struct regmap_config regmap_config = {
>> static const struct mfd_cell ntxec_subdev[] = {
>> { .name = "ntxec-rtc" },
>> { .name = "ntxec-pwm" },
>> + { .name = "ntxec-battery" },
>> };
>>
>> static const struct mfd_cell ntxec_subdev_pwm[] = {
>
> I think that should be a separate patch for mfd.
Okay

> [...]
>> + switch (psp) {
>> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
>> + ret = regmap_read(priv->ec->regmap, NTXEC_REG_READ_BATTERY, &value);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* ec value to microvolt conversion:
>> + * vendor kernel source suggests linear behaviour from 3V to 4.2V
>> + * with readings 767 to 1023; each increment represents 4687,5uV.
>> + * adjust 3V boundary slightly to report exactly 4.2V when full.
>> + */
>> + val->intval = 2999872 + (value - 767) * 4688;
>> + break;
> I find this code both in some kobo 2.6.35.3 code and on the tolino 3.0.35:
>
> const unsigned short battGasgauge[] = {
> // 3.0V, 3.1V, 3.2V, 3.3V, 3.4V, 3.5V, 3.6V, 3.7V, 3.8V, 3.9V, 4.0V, 4.1V, 4.2V,
> // 743, 767, 791, 812, 835, 860, 885, 909, 935, 960, 985, 1010, 1023,
> 767, 791, 812, 833, 852, 877, 903, 928, 950, 979, 993, 1019, 1023,
> };
>
> This does not look very linear... We have offsets
> 24
> 21
> 21
> 19
> 25
> 26
> 25
> 22
> 29
> 14
> 26
> 4
>
> Do you have something looking more sane?
No, I based on the same but simplified it.
> No idea what should produce such flaky offsets besides of
> improper measurements. At least that should be commented.
> And why do these tables exist at all?
>
> Hmm, the more weird thing is that these voltages are translated linearly
> inot capacity.
Indeed - this is why I decided on a linear relationship ...
matching minimal and maixmal voltage as close as possible.

> So maybe they are just adjusted to have the capacity look
> more sane. That would explain the 4 units step between 4.1V and 4.2V.
4.1 is the full voltage of the lion battery if charger was disconnected.
However 4.2 I think is the final voltage reached while charging.

> Having linear adc result -> voltage and nonlinear voltage-> capcity would
> make more sense.
Indeed.
But if it was intended as percentage, then why would he register not
just read from 0-100 :(
So I still guess it is some adc result.

>
> looking at such code snippet like this:
> case POWER_SUPPLY_PROP_CAPACITY:
> if (POWER_SUPPLY_STATUS_NOT_CHARGING == g_ntx_bat_di->battery_status) {
> val->intval = 100;
> return 0;
> }
> value = ntx_up_battery_vol();
> [...]
> val->intval = 100 - ((4100000 - value)/7000);
>
>
> I am wondering whether we should just return capacity that way without
> calculating voltage...
I suppose it depends on whether it is more likely that the ec provides
voltage, or a charge estimation.

br
Josua