Hi Tony, > Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [171018 08:49]: >> >>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: >>> >>> * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [171018 05:49]: >>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@xxxxxx>: >>>>> >>>>> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
