[Letux-kernel] generic-adc-battery

[H. Nikolaus Schaller]

Am 06.02.2016 um 17:50 schrieb H. Nikolaus Schaller <hns at goldelico.com>:

> 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
> convert.
> 
> 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).
> 
> Reasoning:
> * 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.

I should add that this driver should not even be intended to be used for suspend
current measurements... This needs a real fuel gauge.

It is like my car has a quite precise l/km display in the board computer - but the
fuel gauge is not with a display but a classical analog pointer instrument with
1/8 1/4 1/2 3/4 1/1. I.e. it is not possible to find out how many liters are still
in the reservoir. Although it should know...

BR,
Nikolaus