[Letux-kernel] generic-adc-battery

H. Nikolaus Schaller hns at goldelico.com
Sat Feb 6 17:50:39 CET 2016

Hi Andreas,

Am 06.02.2016 um 15:27 schrieb Andreas Kemnade <andreas at kemnade.info>:

> On Sat, 6 Feb 2016 11:26:32 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi,
>>> Am 06.02.2016 um 10:42 schrieb Andreas Kemnade
>>> <andreas at kemnade.info>:
>>> Hi,
>>> On Fri, 5 Feb 2016 23:02:13 +0100
>>> Belisko Marek <marek at goldelico.com> wrote:
>>>> Hi,
>>>> I did look about converting generic-adc-battery to DT and reuse it
>>>> also for our twl4030_madc driver. What I understand is that this
>>>> driver accept in platform_data -> which must be converted to DT,
>>>> battery name, type and other parameters. Some properties which we
>>>> have in twl4030_madc are missing in generic like temperature,
>>>> chargenow but instead there are other which aren't used in
>>>> twl4030_madc (min_design, max_design ..). I did check usage and
>>>> found that it's used only 2 times for LIPO batteries. Basically
>>>> conversion is doable but I'm not sure how community will respond
>>>> to our enhancements (conversion to DT should be OK). So question
>>>> is if we should invest time to this rework? Formula was valid only
>>>> for LioN batteries, not sure if something else exists for LIPO
>>>> batteries type. Suggestions? Thanks.
>>> Do you mean this by formula:
>>>               charging-calibration-data = <4200 100 4100 75 4000
>>> 55 3900 25 3800 5 3700 2 3600 1 3300 0>;
>>> discharging-calibration-data = <4200 100 4100 95 4000 70 3800 50
>>> 3700 10 3600 5 3300 0>;
>>> I do not find this kind of formula useful because it gives only
>>> good values if you are charging with high currents. So it is only
>>> good for limited usecases. If you charge only with low currents
>>> because the device itself draws a lot of current, voltage behaves
>>> like somewhere between charging and discharging. E.g. for 3.8V you
>>> would have something between 5% and 50%.
>>> I doubt if converting something to give the same broken, useless
>>> values to somewhere else is worth any work.
>>> I am not convinced that such a formula belongs into the kernel.
>>> Maybe it does, maybe not.
>>> Userspace does not know that these values are only guesswork.
>>> To have good values there has either to be a formula which
>>> considers both voltage and current or look at power only at well
>>> defined conditions.
>> The problem is that in case of Letux devices w/o bq27000 (e.g. L3704,
>> L7004) there is no charge indication at all.
> here speaks a user of systems without fuel gauge. I had used a gta04
> with dumb battery for quite some time.
> I had a eeepc with a dumb battery. 
>> Most user-spaces are prepared to simply scan /sys/class/power for
>> batteries and find a "charge level" indication there. They are not
>> prepared to detect that there is a battery with uncalibrated data and
>> then do the calibration in user space...
>> This means we need a simple kernel driver that translates voltage to
>> %.
> We are even translating into charge_now (mAh)
> generic-adc-battery seems also to translate into that.

Well, that is trivial and is included in our twl4030-madc-battery.
If the nominal capcaity is known it is a simple multiplication/division to

The tricky part is to get from voltage to % of capacity (or absolute capacity).
>> This all is what this driver is about. Being a fallback if there is
>> no exact fuel gauge. So I would assume a precision of +/-20% is ok...
>> And better than nothing.
> Sometimes nothing might be better.
> Lets take an example:
> Our measure-suspend script
> If there is charge_now but no fuel gauge, it has no other chance than
> to display nonsense. If there is no charge_now but only capacity it can
> refuse to run.
> It does not even have +/-20%
> root at gta04:~# cat /sys/class/power_supply/twl4030_battery/capacity 
> 32
> root at gta04:~# cat /sys/class/power_supply/bq27000-battery/capacity
> 61
> +/- 20% would be 49...73%
> after turning charging off:
> root at gta04:~# cat /sys/class/power_supply/twl4030_battery/capacity 
> 59
> after playing again with device settings a bit:
> root at gta04:~# cat /sys/class/power_supply/twl4030_battery/capacity 
> 10
> root at gta04:~# cat /sys/class/power_supply/bq27000-battery/capacity
> 57
> So what? Do I have 60% or 10%? That makes quite a difference.
> 10% might cause userspace to do some harder power saving measures
> which might cause discomfort.
> Maybe there is something wrong in the driver. I am surprised how
> bad the values are. I repeated each measurement some times.

Yes, I also have the impression that it has become worse and may have
a bug (perhaps some iio API has changed). When Lukas developed the
non-DT version it worked well and when we started to convert to DT some
years ago.

Maybe the batteries we use have become worse? So their inner resistance
has increased? This could also make a difference.

> If I see numbers I expect a certain accuracy. If battery charge is
> displayed as something like three segments that is a clear indication
> that numbers are not accurate e.g. it is not known whether battery has
> 30% or only 10%.
> IMHO such dumb battery drivers only make sense if they can indicate to
> userspace that there is only guesswork. So maybe that sysfs interface
> is bad. 

Well, as said, my view is that there is a *standard* interface how batteries
can be reported by /sys/class/power.

And capacity should be reported between 0% and 100% (and 0mAh and max mAh).

Both end points are easy to solve. <3.3V is 0%. 4.2V is 100%. The problem
is only how the curve runs between these calibration points.

A general problem is the twl4030 hardware which does not allow to measure
how much current is going into the battery or coming out. It can only measure
the USB charging current. And it never can know the discharge current.

But we can estimate:
a) GTA04 with display on and standard operation: 400 mA
b) during suspend 25-50 mA
c) with WLAN full operation: 600 mA
d) with WLAN + 3G operation: 800 mA

From this I would calibrate for a).

* if the system draws more current, the voltage goes down (impedance of battery)
and it will atumatically show less %. Since it is the high current situation, it does
IMHO not harm if the battery lasts longer than indicated
* if the system is in suspend, nobody checks for the %, so it does not harm if
it would show a wrong value
* if you do suspend measurements, the system wakes up when you ask the
battery driver next time, i.e. is again in a 400mA state.


More information about the Letux-kernel mailing list