[Letux-kernel] generic-adc-battery

[Andreas Kemnade]

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.
 
> 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.

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. 

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20160206/1e0311e8/attachment.asc>