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

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

[Pavel Machek]

Hi!

> > Without patch description: See Last Question in
> > 
> > Documentation/power/power_supply_class.txt
> 
> ...should be done in libbattery, yet to be written. :-).
> 
> Do you have specific guidance what you'd like to see in libbattery?

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.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/fb6dfa3d/attachment.sig>

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

[H. Nikolaus Schaller]

> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Without patch description: See Last Question in
>>> 
>>> Documentation/power/power_supply_class.txt
>> 
>> ...should be done in libbattery, yet to be written. :-).
>> 
>> Do you have specific guidance what you'd like to see in libbattery?

IMHO there was no answer from maintainers. Or I have not received it.

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

With using generic-adc-battery driver and Marek's patch in kernel, this can easily be provided.

With exactly 0 bits of change in user space. Please note that you can't always tell users "upgrade to the latest user space".

So I have three questions:
a) why do you use float/double instead of fixed point for such simple and imprecise calculations?
b) what does it provide as additional information over some lines of code in generic-adc-battery driver?
c) how do yo make sure that this libbattery is included in all the battery monitors that are already in use and
is backported for example to the old plugin I mentioned above?

BR and thanks,
Nikolaus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/e83b4fb5/attachment.sig>

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

[Pavel Machek]

> So I have three questions:
> a) why do you use float/double instead of fixed point for such
> simple and imprecise calculations?

Cleaner code, and probably faster, too.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/691a6ed3/attachment.sig>

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

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > 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.

Regards,

Tony

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

[Pavel Machek]

On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > > 
> > > 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.

Hmm. This could be as simple as providing symlink from
/sys/class/power/userland-battery to some place writable by
userspace...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/98eb36a1/attachment.sig>

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

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>> 
>>>> 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.
> 
> Hmm. This could be as simple as providing symlink from
> /sys/class/power/userland-battery to some place writable by
> userspace...

Well, please implement arbitrary symlinks in /sysfs...

root at letux:~# ln -sf /tmp/somewhere /sys/class/power_supply/fake-battery
ln: failed to create symbolic link '/sys/class/power_supply/fake-battery': Operation not permitted
root at letux:~#

And you need to run a daemon so that the data is available
somewhere.

BR and thanks,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/ded7a77f/attachment.sig>

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

[Pavel Machek]

On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
> 
> > Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> >> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>> 
> >>>> 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.
> > 
> > Hmm. This could be as simple as providing symlink from
> > /sys/class/power/userland-battery to some place writable by
> > userspace...
> 
> Well, please implement arbitrary symlinks in /sysfs...

Any reason why I'd like to do that?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/fb198e83/attachment.sig>

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

[H. Nikolaus Schaller]

> Am 18.10.2017 um 18:13 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>> 
>>>>>> 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.
>>> 
>>> Hmm. This could be as simple as providing symlink from
>>> /sys/class/power/userland-battery to some place writable by
>>> userspace...
>> 
>> Well, please implement arbitrary symlinks in /sysfs...
> 
> Any reason why I'd like to do that?

I don't know if you like it or not.

But it appears to be a strict necessity to make your proposal of
"as simple as providing symlink from /sys/class/power/userland-battery
to some place writable by userspace" work.

So if a different solution to provide /sys/class/power/*-battery
is possible, it should probably be preferred and nobody will ask
you to do something you don't like.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/b7bb8503/attachment.sig>

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

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> 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.
Why not have the kernel driver do the simple calculations (they do
not need float) and provide the standard /sys/class/power attribute?

BR,
Nikolaus

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

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> 
> > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>> 
> >>> 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.

> 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. This
data needs to be preserved across reboots, so most likely on a file
on a disk is the way to go.

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

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

Regards,

Tony

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

[H. Nikolaus Schaller]

Hi Tony,

> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>> 
>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>> 
>>>>> 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

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

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
> Hi Tony,
> 
> > Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> >> 
> >>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> >>> 
> >>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>>> 
> >>>>> 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%.

Right, I was discussing Pavel's libbattery link posted above. No
comments on the current patch series. Let's move the libbattery stuff
to a new thread to avoid confusion.

Regards,

Tony

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

[H. Nikolaus Schaller]

> Am 19.10.2017 um 19:06 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
>> Hi Tony,
>> 
>>> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>>>> 
>>>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>>>> 
>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>>> 
>>>>>>> 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%.
> 
> Right, I was discussing Pavel's libbattery link posted above. No
> comments on the current patch series.

Well, it was triggered by Sebastian's comment on this patch that 
some 10 years old Documentation recommends to write a libbattery.

And there is still some (weak) relation between the subject and libbattery.

> Let's move the libbattery stuff
> to a new thread to avoid confusion.

Agreed.

BR,
Nikolaus

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

[Ladislav Michl]

On Thu, Oct 19, 2017 at 09:24:16AM -0700, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> > 
> > > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > > 
> > > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > >>> 
> > >>> 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.
> 
> > 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. This
> data needs to be preserved across reboots, so most likely on a file
> on a disk is the way to go.

Well, a lot of gas gauches have registers to store that kind of information.
Just noone uses them and that's another part of story.
This one I'm using for such purposes, but as I didn't figure out what is
standard way of dealing wich such kind of information, I'm lock with
this solution for now.

Subject: [PATCH] power: supply: ltc2941-battery-gauge: charge empty and full

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 drivers/power/supply/ltc2941-battery-gauge.c | 59 +++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/ltc2941-battery-gauge.c b/drivers/power/supply/ltc2941-battery-gauge.c
index 08e4fd9ee607..523373ea9cbd 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -34,6 +34,10 @@ enum ltc294x_reg {
 	LTC294X_REG_CONTROL		= 0x01,
 	LTC294X_REG_ACC_CHARGE_MSB	= 0x02,
 	LTC294X_REG_ACC_CHARGE_LSB	= 0x03,
+	LTC294X_REG_CHARGE_THR_HIGH_MSB	= 0x04,
+	LTC294X_REG_CHARGE_THR_HIGH_LSB	= 0x05,
+	LTC294X_REG_CHARGE_THR_LOW_MSB	= 0x06,
+	LTC294X_REG_CHARGE_THR_LOW_LSB	= 0x07,
 	LTC294X_REG_VOLTAGE_MSB		= 0x08,
 	LTC294X_REG_VOLTAGE_LSB		= 0x09,
 	LTC2942_REG_TEMPERATURE_MSB	= 0x0C,
@@ -178,21 +182,22 @@ static int ltc294x_reset(const struct ltc294x_info *info, int prescaler_exp)
 	return ret;
 }
 
-static int ltc294x_read_charge_register(const struct ltc294x_info *info)
-{
+static int ltc294x_read_charge_register(const struct ltc294x_info *info,
+					enum ltc294x_reg reg)
+ {
 	int ret;
 	u8 datar[2];
 
-	ret = ltc294x_read_regs(info->client,
-		LTC294X_REG_ACC_CHARGE_MSB, &datar[0], 2);
+	ret = ltc294x_read_regs(info->client, reg, &datar[0], 2);
 	if (ret < 0)
 		return ret;
 	return (datar[0] << 8) + datar[1];
 }
 
-static int ltc294x_get_charge_now(const struct ltc294x_info *info, int *val)
+static int ltc294x_get_charge(const struct ltc294x_info *info,
+				enum ltc294x_reg reg, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, reg);
 
 	if (value < 0)
 		return value;
@@ -244,10 +249,29 @@ static int ltc294x_set_charge_now(const struct ltc294x_info *info, int val)
 	return ret < 0 ? ret : 0;
 }
 
+static int ltc294x_set_charge_thr(const struct ltc294x_info *info,
+					enum ltc294x_reg reg, int val)
+{
+	u8 dataw[2];
+	s32 value;
+
+	value = convert_uAh_to_bin(info, val);
+	/* Direction depends on how sense+/- were connected */
+	if (info->Qlsb < 0)
+		value += 0xFFFF;
+	if ((value < 0) || (value > 0xFFFF)) /* input validation */
+		return -EINVAL;
+
+	/* Set new charge value */
+	dataw[0] = I16_MSB(value);
+	dataw[1] = I16_LSB(value);
+	return ltc294x_write_regs(info->client, reg, &dataw[0], 2);
+}
+
 static int ltc294x_get_charge_counter(
 	const struct ltc294x_info *info, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (value < 0)
 		return value;
@@ -335,8 +359,15 @@ static int ltc294x_get_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (prop) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_HIGH_MSB,
+						&val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_LOW_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
-		return ltc294x_get_charge_now(info, &val->intval);
+		return ltc294x_get_charge(info, LTC294X_REG_ACC_CHARGE_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_COUNTER:
 		return ltc294x_get_charge_counter(info, &val->intval);
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -357,6 +388,12 @@ static int ltc294x_set_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_HIGH_MSB, val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_LOW_MSB, val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return ltc294x_set_charge_now(info, val->intval);
 	default:
@@ -368,6 +405,8 @@ static int ltc294x_property_is_writeable(
 	struct power_supply *psy, enum power_supply_property psp)
 {
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return 1;
 	default:
@@ -377,7 +416,7 @@ static int ltc294x_property_is_writeable(
 
 static void ltc294x_update(struct ltc294x_info *info)
 {
-	int charge = ltc294x_read_charge_register(info);
+	int charge = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (charge != info->charge) {
 		info->charge = charge;
@@ -396,6 +435,8 @@ static void ltc294x_work(struct work_struct *work)
 
 static enum power_supply_property ltc294x_properties[] = {
 	POWER_SUPPLY_PROP_CHARGE_COUNTER,
+	POWER_SUPPLY_PROP_CHARGE_FULL,
+	POWER_SUPPLY_PROP_CHARGE_EMPTY,
 	POWER_SUPPLY_PROP_CHARGE_NOW,
 	POWER_SUPPLY_PROP_VOLTAGE_NOW,
 	POWER_SUPPLY_PROP_TEMP,
-- 
2.11.0

> There's a nice summary what all is involved here:
> 
> http://www.mpoweruk.com/soc.htm
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html