Hi Tony,

Am 19.10.2017 um 18:24 schrieb Tony Lindgren [off-list ref]:

* H. Nikolaus Schaller [off-list ref] [171018 08:49]:

quoted

quoted

Am 18.10.2017 um 15:22 schrieb Tony Lindgren [off-list ref]:

* H. Nikolaus Schaller [off-list ref] [171018 05:49]:

quoted

quoted

Am 18.10.2017 um 14:28 schrieb Pavel Machek [off-list ref]:

So I started something, it is at.

https://github.com/pavelmachek/libbattery

My battery on n900 is currently uncalibrated (and charging), still it
gets some kind of estimation:

Battery -1 %
Seconds -1
State 1
Voltage 3.88 V
Battery 63 %

Of course, there's a lot more work to be done.

Nice start but not a solution to our problem.

Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
displays the battery percentage.

I think we could make things compatible with various battery apps by
having libbattery write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry. Then the kernel interface
can just display the data to whatever apps.

Hm. That would be quite difficult to understand and maintain code.

How so? The libbattery can do it all, then the kernel drivers needing
that will just display the most recent values to maintain compability
with battery apps.

Well, it looks as if you are thinking about a much more complex solution
than I am...

The proposal we are discussing as

[RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

just reads the current voltage, charging current and uses a (nonlinear)
mapping to 0% .. 100%.

For that we don't need a library, and we don't need a mechanism to

"write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry.

quoted

Why not have the kernel driver do the simple calculations (they do
not need float) and provide the standard /sys/class/power attribute?

Because the current remaining capacity and battery empty state depend
on maintaining a database of previous history for battery wear.

For remaining capacity I agree that you need that. But this RFC doesn't
even want to provide remaining capacity. To avoid such issues. Just
provide POWER_SUPPLY_PROP_CAPACITY:

https://lkml.org/lkml/2017/8/1/910

So we are discussing to replace these 10 lines with a library, a
daemon and a mechanism that the driver can read that from user space?

IMHO this can be added in a further step, but shouldn't be backpacked
onto this here.

This
data needs to be preserved across reboots, so most likely on a file
on a disk is the way to go.

It could also be stored in some i2c eeprom (DT could provide a reference).

There's a nice summary what all is involved here:

http://www.mpoweruk.com/soc.htm

Oh yes, that is really nice!

Using their terms, we just want to add "Voltage Based SOC Estimation"
for typical "Lithium chemistry".

BTW: this already exists in the twl4030-madc-battery driver and we use it
for the GTA04 derivatives without fuel gauge:

http://elixir.free-electrons.com/linux/v3.17/source/drivers/power/twl4030_madc_battery.c

It uses a table driven approach which was rejected to be converted to DT
some time ago. DT maintainers asked to use an estimation formula instead
of a table and interpolation.

And this patch set does not want to solve all problems in one step :)

But it wants to:
* make it useable for any battery voltage providing iio adc and not only twl4030
  by modifying the generic-adc-battery driver
* make the driver device tree compatible (twl4030-madc-battery still isn't)
* replace table by fixed point estimation formula fuel_level_LiIon(() as requested

Not more.

Of course a libbattery can do a lot of additional calculations to predict
e.g. time to emtpy or full charge, estimate battery health etc. and provide
more precision by filters.

We would be very happy to have a simple estimation because it already
covers most use cases (some early smartphones had only 4 levels for SOC).
And we want to replace the pdata based driver with a DT driver asap.

BR and thanks,
Nikolaus