Discussion:
[PATCH] battery: Fix charge_now returned by broken batteries
(too old to reply)
Miguel Ojeda
2009-10-04 17:46:42 UTC
Permalink
On Sun, Oct 4, 2009 at 6:45 PM, Henrique de Moraes Holschuh
Some broken batteries like my DELL NR2227 or a friend's DELL GK4798 =
return
the design_capacity (charge_full_design) as capacity_now (charge_now=
)
when completely charged.
I noticed this when looking at a battery plugin that reported "127% =
charged".
Some of these plugins have already "fixed" this in userspace by codi=
ng
something like min(percentage, 100)).
A battery can be charged above 100%. =A0It just depends what you call=
100%,
and the "I am full" level *varies* in a non-monotonic way during the =
battery
lifetime...
So, if you don't want to see > 100%, you have to clamp it to 100% and=
lose
information (when your "100%" level is actually increasing as the thi=
ng
keeps charging and you keep raising the baseline so that it doesn't g=
o over
100%).
If the 100% level increased, then full_charge_capacity (a.k.a. "_last_
full capacity" as seen in /proc) will increase as well, won't it? If
the battery went over that 100% that means there is a "new" 100%, why
are we losing information?.

I am asking, I am not an expert on battery stuff.
So I discovered that the battery wrongly returns charge_full_design =
when
completely charged instead of charge_full.
Ick.
This patch fixes this by returning min(capacity_now, full_charge_cap=
acity)
on both procfs and sysfs.
What will it cause on non-broken batteries? =A0Or during gauge reset,=
when any
battery that updates full_charge_capacity only at the end of the cycl=
e will
really have capacity_now > full_charge_capacity ?
Well, does it make sense to have capacity_now higher than
full_charge_capacity? Wouldn't that information be broken too?

Again, I am just wondering.
Now the userspace plugins report the correct 100% and their userspac=
e check
may not be needed (if this error is the only one producing >100% res=
ults).
Like I said, > 100% can happen, unless what you define to be 100% is =
very
elastic (and gets updated all the time).
I still think it does not make sense to have a battery charged over
its 100% capacity whatever the definition of 100% is. Maybe I do not
understand your point.
--
=A0"One disk to rule them all, One disk to find them. One disk to bri=
ng
=A0them all and in the darkness grind them. In the Land of Redmond
=A0where the shadows lie." -- The Silicon Valley Tarot
=A0Henrique Holschuh
Henrique de Moraes Holschuh
2009-10-04 16:45:53 UTC
Permalink
Some broken batteries like my DELL NR2227 or a friend's DELL GK4798 return
the design_capacity (charge_full_design) as capacity_now (charge_now)
when completely charged.
I noticed this when looking at a battery plugin that reported "127% charged".
Some of these plugins have already "fixed" this in userspace by coding
something like min(percentage, 100)).
A battery can be charged above 100%. It just depends what you call 100%,
and the "I am full" level *varies* in a non-monotonic way during the battery
lifetime...

So, if you don't want to see > 100%, you have to clamp it to 100% and lose
information (when your "100%" level is actually increasing as the thing
keeps charging and you keep raising the baseline so that it doesn't go over
100%).
So I discovered that the battery wrongly returns charge_full_design when
completely charged instead of charge_full.
Ick.
This patch fixes this by returning min(capacity_now, full_charge_capacity)
on both procfs and sysfs.
What will it cause on non-broken batteries? Or during gauge reset, when any
battery that updates full_charge_capacity only at the end of the cycle will
really have capacity_now > full_charge_capacity ?
Now the userspace plugins report the correct 100% and their userspace check
may not be needed (if this error is the only one producing >100% results).
Like I said, > 100% can happen, unless what you define to be 100% is very
elastic (and gets updated all the time).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexey Starikovskiy
2009-10-04 18:57:47 UTC
Permalink
Hi Miguel,

I am going to reject your patch on the basis, that the battery driver s=
hould report only
information it gained from battery hardware, not interpret it in any wa=
y.
As your patch fall into "interpret" category, it does not belong in the=
kernel and battery
driver in particular. You may suggest it to any/all user space battery =
monitoring applications,
this is the place for "interpretations".

Not-acknowledged-by: Alexey Starikovskiy


Regards,
Alex.
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 6:45 PM, Henrique de Moraes Holschuh
Some broken batteries like my DELL NR2227 or a friend's DELL GK4798=
return
Post by Miguel Ojeda
the design_capacity (charge_full_design) as capacity_now (charge_no=
w)
Post by Miguel Ojeda
when completely charged.
I noticed this when looking at a battery plugin that reported "127%=
charged".
Post by Miguel Ojeda
Some of these plugins have already "fixed" this in userspace by cod=
ing
Post by Miguel Ojeda
something like min(percentage, 100)).
A battery can be charged above 100%. It just depends what you call =
100%,
Post by Miguel Ojeda
and the "I am full" level *varies* in a non-monotonic way during the=
battery
Post by Miguel Ojeda
lifetime...
So, if you don't want to see > 100%, you have to clamp it to 100% an=
d lose
Post by Miguel Ojeda
information (when your "100%" level is actually increasing as the th=
ing
Post by Miguel Ojeda
keeps charging and you keep raising the baseline so that it doesn't =
go over
Post by Miguel Ojeda
100%).
=20
If the 100% level increased, then full_charge_capacity (a.k.a. "_last=
_
Post by Miguel Ojeda
full capacity" as seen in /proc) will increase as well, won't it? If
the battery went over that 100% that means there is a "new" 100%, why
are we losing information?.
=20
I am asking, I am not an expert on battery stuff.
=20
So I discovered that the battery wrongly returns charge_full_design=
when
Post by Miguel Ojeda
completely charged instead of charge_full.
Ick.
This patch fixes this by returning min(capacity_now, full_charge_ca=
pacity)
Post by Miguel Ojeda
on both procfs and sysfs.
What will it cause on non-broken batteries? Or during gauge reset, =
when any
Post by Miguel Ojeda
battery that updates full_charge_capacity only at the end of the cyc=
le will
Post by Miguel Ojeda
really have capacity_now > full_charge_capacity ?
=20
Well, does it make sense to have capacity_now higher than
full_charge_capacity? Wouldn't that information be broken too?
=20
Again, I am just wondering.
=20
Now the userspace plugins report the correct 100% and their userspa=
ce check
Post by Miguel Ojeda
may not be needed (if this error is the only one producing >100% re=
sults).
Post by Miguel Ojeda
Like I said, > 100% can happen, unless what you define to be 100% is=
very
Post by Miguel Ojeda
elastic (and gets updated all the time).
=20
I still think it does not make sense to have a battery charged over
its 100% capacity whatever the definition of 100% is. Maybe I do not
understand your point.
=20
--
"One disk to rule them all, One disk to find them. One disk to brin=
g
Post by Miguel Ojeda
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Rafael J. Wysocki
2009-10-04 20:46:23 UTC
Permalink
Post by Alexey Starikovskiy
Hi Miguel,
Hi Alex,
Post by Alexey Starikovskiy
I am going to reject your patch on the basis, that the battery driver should report only
information it gained from battery hardware, not interpret it in any way.
As your patch fall into "interpret" category, it does not belong in the kernel and battery
driver in particular. You may suggest it to any/all user space battery monitoring applications,
this is the place for "interpretations".
Well, we do quirks for PCI devices, suspend quirks etc. in the kernel, so I'm
not really sure we should use the "no interpretation" as a general rule. IMO,
if there's a known broken system needing a quirk, it may just be more
reasonable to put the quirk into the kernel than to put it into every single
user application out there.

In this particular case we have an evidently quirky hardware (or BIOS) and it's
not a fundamentally wrong idea to try to address that problem in the kernel.

Thanks,
Rafael
Alexey Starikovskiy
2009-10-04 21:36:56 UTC
Permalink
Hi Rafael,

This is not my rule, it was/is the rule of power device class. If you d=
o not agree to it, please change
appropriate documentation.

Regards,
Alex.
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
Hi Miguel,
=20
Hi Alex,
=20
Post by Alexey Starikovskiy
I am going to reject your patch on the basis, that the battery drive=
r should report only
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
information it gained from battery hardware, not interpret it in any=
way.
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
As your patch fall into "interpret" category, it does not belong in =
the kernel and battery
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
driver in particular. You may suggest it to any/all user space batte=
ry monitoring applications,
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
this is the place for "interpretations".
=20
Well, we do quirks for PCI devices, suspend quirks etc. in the kernel=
, so I'm
Post by Rafael J. Wysocki
not really sure we should use the "no interpretation" as a general ru=
le. IMO,
Post by Rafael J. Wysocki
if there's a known broken system needing a quirk, it may just be more
reasonable to put the quirk into the kernel than to put it into every=
single
Post by Rafael J. Wysocki
user application out there.
=20
In this particular case we have an evidently quirky hardware (or BIOS=
) and it's
Post by Rafael J. Wysocki
not a fundamentally wrong idea to try to address that problem in the =
kernel.
Post by Rafael J. Wysocki
=20
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-04 21:55:21 UTC
Permalink
On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
This is not my rule, it was/is the rule of power device class. If you=
do not
Post by Alexey Starikovskiy
agree to it, please change
appropriate documentation.
Oh, I did not know that. Thank you for pointing it out. I think you
are refering to:

158Q: Suppose, my battery monitoring chip/firmware does not provides c=
apacity
159 in percents, but provides charge_{now,full,empty}. Should I calc=
ulate
160 percentage capacity manually, inside the driver, and register CA=
PACITY
161 attribute? The same question about time_to_empty/time_to_full.
162A: Most likely, no. This class is designed to export properties whi=
ch are
163 directly measurable by the specific hardware available.
164
165 Inferring not available properties using some heuristics or math=
ematical
166 model is not subject of work for a battery driver. Such function=
ality
167 should be factored out, and in fact, apm_power, the driver to se=
rve
168 legacy APM API on top of power supply class, uses a simple heuri=
stic of
169 approximating remaining battery capacity based on its charge, cu=
rrent,
170 voltage and so on. But full-fledged battery model is likely not =
subject
171 for kernel at all, as it would require floating point calculatio=
n to deal
172 with things like differential equations and Kalman filters. This=
is
173 better be handled by batteryd/libbattery, yet to be written.

We are not calculating anything new just by the pleasure of doing it,
we are correcting a wrong value provided by the hardware.

Please correct me if I misunderstood you.
Post by Alexey Starikovskiy
Regards,
Alex.
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
Hi Miguel,
Hi Alex,
Post by Alexey Starikovskiy
I am going to reject your patch on the basis, that the battery driv=
er
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
should report only
information it gained from battery hardware, not interpret it in an=
y way.
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
As your patch fall into "interpret" category, it does not belong in=
the
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
kernel and battery
driver in particular. You may suggest it to any/all user space batt=
ery
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
Post by Alexey Starikovskiy
monitoring applications,
this is the place for "interpretations".
Well, we do quirks for PCI devices, suspend quirks etc. in the kerne=
l, so
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
I'm
not really sure we should use the "no interpretation" as a general r=
ule.
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
=C2=A0IMO,
if there's a known broken system needing a quirk, it may just be mor=
e
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
reasonable to put the quirk into the kernel than to put it into ever=
y
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
single
user application out there.
In this particular case we have an evidently quirky hardware (or BIO=
S) and
Post by Alexey Starikovskiy
Post by Rafael J. Wysocki
it's
not a fundamentally wrong idea to try to address that problem in the kernel.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexey Starikovskiy
2009-10-04 22:38:44 UTC
Permalink
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
This is not my rule, it was/is the rule of power device class. If yo=
u do not
Post by Miguel Ojeda
Post by Alexey Starikovskiy
agree to it, please change
appropriate documentation.
=20
Oh, I did not know that. Thank you for pointing it out. I think you
=20
158Q: Suppose, my battery monitoring chip/firmware does not provides=
capacity
Post by Miguel Ojeda
159 in percents, but provides charge_{now,full,empty}. Should I ca=
lculate
Post by Miguel Ojeda
160 percentage capacity manually, inside the driver, and register =
CAPACITY
Post by Miguel Ojeda
161 attribute? The same question about time_to_empty/time_to_full.
162A: Most likely, no. This class is designed to export properties w=
hich are
Post by Miguel Ojeda
163 directly measurable by the specific hardware available.
164
165 Inferring not available properties using some heuristics or ma=
thematical
Post by Miguel Ojeda
166 model is not subject of work for a battery driver. Such functi=
onality
Post by Miguel Ojeda
167 should be factored out, and in fact, apm_power, the driver to =
serve
Post by Miguel Ojeda
168 legacy APM API on top of power supply class, uses a simple heu=
ristic of
Post by Miguel Ojeda
169 approximating remaining battery capacity based on its charge, =
current,
Post by Miguel Ojeda
170 voltage and so on. But full-fledged battery model is likely no=
t subject
Post by Miguel Ojeda
171 for kernel at all, as it would require floating point calculat=
ion to deal
Post by Miguel Ojeda
172 with things like differential equations and Kalman filters. Th=
is is
Post by Miguel Ojeda
173 better be handled by batteryd/libbattery, yet to be written.
=20
We are not calculating anything new just by the pleasure of doing it,
we are correcting a wrong value provided by the hardware.
You are guessing that normal battery can not jump charge value, and on =
this assumption you
cap charge_now with last full_charge. Immediate problem is that full_ch=
arge is not fixed value,
this is why it is separated from design_full_charge.
During battery life full_charge may go down and up, depending on outsid=
e temperature, battery discharge (full or partial).
I've seen batteries on some new machines reporting full charge of more =
than design charge.
Obviously, your patch will fail in some of the above situations.
Currently, reading from the driver is "last resort" to get un-interpret=
ed value, if you have any doubts on it. With
your patch, this is gone, and user space will have to interpret results=
of kernel interpreter.

Return to the "bug still exists". We are referring to the value, which =
can not be measured directly with any known device.
Thus, it may be completely sane that battery manufacturer provides you =
with some charge curve, but knows only two values on it
which he may trust -- point where he can not get any power out of it (c=
omplete discharge) and point where he can not put any additional charge=
into the battery (due to various stop conditions (battery temperature =
being one)). In such a case manufacturer may choose to adjust charge cu=
rve to end up always at design_full_charge point, no matter how much of=
adjustment this requires.

Do you have the same jump from >100% to 99% on discharge?

Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-04 23:53:16 UTC
Permalink
On Mon, Oct 5, 2009 at 12:38 AM, Alexey Starikovskiy
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
This is not my rule, it was/is the rule of power device class. If y=
ou do
Post by Miguel Ojeda
Post by Alexey Starikovskiy
not
agree to it, please change
appropriate documentation.
Oh, I did not know that. Thank you for pointing it out. I think you
=C2=A0158Q: Suppose, my battery monitoring chip/firmware does not pr=
ovides
Post by Miguel Ojeda
capacity
=C2=A0159 =C2=A0 in percents, but provides charge_{now,full,empty}. =
Should I
Post by Miguel Ojeda
calculate
=C2=A0160 =C2=A0 percentage capacity manually, inside the driver, an=
d register
Post by Miguel Ojeda
CAPACITY
=C2=A0161 =C2=A0 attribute? The same question about time_to_empty/ti=
me_to_full.
Post by Miguel Ojeda
=C2=A0162A: Most likely, no. This class is designed to export proper=
ties which
Post by Miguel Ojeda
are
=C2=A0163 =C2=A0 directly measurable by the specific hardware availa=
ble.
Post by Miguel Ojeda
=C2=A0164
=C2=A0165 =C2=A0 Inferring not available properties using some heuri=
stics or
Post by Miguel Ojeda
mathematical
=C2=A0166 =C2=A0 model is not subject of work for a battery driver. =
Such
Post by Miguel Ojeda
functionality
=C2=A0167 =C2=A0 should be factored out, and in fact, apm_power, the=
driver to serve
Post by Miguel Ojeda
=C2=A0168 =C2=A0 legacy APM API on top of power supply class, uses a=
simple
Post by Miguel Ojeda
heuristic of
=C2=A0169 =C2=A0 approximating remaining battery capacity based on i=
ts charge,
Post by Miguel Ojeda
current,
=C2=A0170 =C2=A0 voltage and so on. But full-fledged battery model i=
s likely not
Post by Miguel Ojeda
subject
=C2=A0171 =C2=A0 for kernel at all, as it would require floating poi=
nt calculation
Post by Miguel Ojeda
to deal
=C2=A0172 =C2=A0 with things like differential equations and Kalman =
filters. This is
Post by Miguel Ojeda
=C2=A0173 =C2=A0 better be handled by batteryd/libbattery, yet to be=
written.
Post by Miguel Ojeda
We are not calculating anything new just by the pleasure of doing it=
,
Post by Miguel Ojeda
we are correcting a wrong value provided by the hardware.
You are guessing that normal battery can not jump charge value, and o=
n this
assumption you
cap charge_now with last full_charge. Immediate problem is that full_=
charge
is not fixed value,
this is why it is separated from design_full_charge.
During battery life full_charge may go down and up, depending on outs=
ide
temperature, battery discharge (full or partial).
I've seen batteries on some new machines reporting full charge of mor=
e than
design charge.
Obviously, your patch will fail in some of the above situations.
I don't see why. The patch compares against full_charge every time
(which is updated as you say), not against design_full_charge.

1. full_charge > design_full_charge =3D> OK, design_full_charge is not
involved in the min() operation.
2. full_charge goes down =3D> If charge_now > full_charge then hardware
is wrong and we should read full_charge. OK.
3. full_charge goes up =3D> Same.

What do you mean by failing in such situations? My point is that,
AFAIK charge_now shouldn't be higher than full_charge *. The patch
does not care about design_full_charge, neither the original code.

* I do not know about some overcharging issues that Henrique mentioned.
Currently, reading from the driver is "last resort" to get un-interpr=
eted
value, if you have any doubts on it. With
your patch, this is gone, and user space will have to interpret resul=
ts of
kernel interpreter.
Return to the "bug still exists". We are referring to the value, whic=
h can
not be measured directly with any known device.
Thus, it may be completely sane that battery manufacturer provides yo=
u with
some charge curve, but knows only two values on it
which he may trust -- point where he can not get any power out of it
(complete discharge) and point where he can not put any additional ch=
arge
into the battery (due to various stop conditions (battery temperature=
being
one)). In such a case manufacturer may choose to adjust charge curve =
to end
up always at design_full_charge point, no matter how much of adjustme=
nt this
requires.
I understand that and you may be right; however, AFAIK, a userspace
application has no way to know that it should compare against
full_charge every time _except_ when in "charged" state, has it? Is
there any kind of protocol/documentation that establish what an
userspace application should do?

The battery reports correctly full_charge in order to compare with
charge_now (and as I checked, some userspace plugins always check
against that full_charge, not design_full_charge, which seems to be
the logical thing to do, who cares what the design full charge level
was when reporting the actual charge level?).
Do you have the same jump from >100% to 99% on discharge?
Yes: When in "charged" state, the battery reports a fixed value
(desing_full_charge, it is always the same). In "charging" or
"discharging" it correctly reports the current charge. It also
correctly reports full_charge, not matter what state.

So, maybe the battery works as you suggested; still, the kernel should
provide a common meaning to its interfaces. If some batteries report
full_charge when in "charged" state and others report
design_full_charge, then the kernel should convert all of them into
one unique convention, or there is no sane way to write userspace
applications.
Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexey Starikovskiy
2009-10-05 00:18:13 UTC
Permalink
Post by Miguel Ojeda
On Mon, Oct 5, 2009 at 12:38 AM, Alexey Starikovskiy
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
This is not my rule, it was/is the rule of power device class. If =
you do
Post by Miguel Ojeda
Post by Miguel Ojeda
Post by Alexey Starikovskiy
not
agree to it, please change
appropriate documentation.
Oh, I did not know that. Thank you for pointing it out. I think you
158Q: Suppose, my battery monitoring chip/firmware does not provid=
es
Post by Miguel Ojeda
Post by Miguel Ojeda
capacity
159 in percents, but provides charge_{now,full,empty}. Should I
calculate
160 percentage capacity manually, inside the driver, and registe=
r
Post by Miguel Ojeda
Post by Miguel Ojeda
CAPACITY
161 attribute? The same question about time_to_empty/time_to_ful=
l.
Post by Miguel Ojeda
Post by Miguel Ojeda
162A: Most likely, no. This class is designed to export properties=
which
Post by Miguel Ojeda
Post by Miguel Ojeda
are
163 directly measurable by the specific hardware available.
164
165 Inferring not available properties using some heuristics or
mathematical
166 model is not subject of work for a battery driver. Such
functionality
167 should be factored out, and in fact, apm_power, the driver t=
o serve
Post by Miguel Ojeda
Post by Miguel Ojeda
168 legacy APM API on top of power supply class, uses a simple
heuristic of
169 approximating remaining battery capacity based on its charge=
,
Post by Miguel Ojeda
Post by Miguel Ojeda
current,
170 voltage and so on. But full-fledged battery model is likely =
not
Post by Miguel Ojeda
Post by Miguel Ojeda
subject
171 for kernel at all, as it would require floating point calcul=
ation
Post by Miguel Ojeda
Post by Miguel Ojeda
to deal
172 with things like differential equations and Kalman filters. =
This is
Post by Miguel Ojeda
Post by Miguel Ojeda
173 better be handled by batteryd/libbattery, yet to be written.
We are not calculating anything new just by the pleasure of doing i=
t,
Post by Miguel Ojeda
Post by Miguel Ojeda
we are correcting a wrong value provided by the hardware.
You are guessing that normal battery can not jump charge value, and =
on this
Post by Miguel Ojeda
assumption you
cap charge_now with last full_charge. Immediate problem is that full=
_charge
Post by Miguel Ojeda
is not fixed value,
this is why it is separated from design_full_charge.
During battery life full_charge may go down and up, depending on out=
side
Post by Miguel Ojeda
temperature, battery discharge (full or partial).
I've seen batteries on some new machines reporting full charge of mo=
re than
Post by Miguel Ojeda
design charge.
Obviously, your patch will fail in some of the above situations.
=20
I don't see why. The patch compares against full_charge every time
(which is updated as you say), not against design_full_charge.
=20
1. full_charge > design_full_charge =3D> OK, design_full_charge is no=
t
Post by Miguel Ojeda
involved in the min() operation.
2. full_charge goes down =3D> If charge_now > full_charge then hardwa=
re
Post by Miguel Ojeda
is wrong and we should read full_charge. OK.
3. full_charge goes up =3D> Same.
full_charge_capacity is the value of last full charge. It will be updat=
ed to
current full charge, when the charging is complete. It may end up lower=
or greater than
previous value.
Comparing current charge with the last full charge may correctly give y=
ou >100%.
Now we have a decision to make -- do we update full charge to be greate=
r than charge now,
or do we update charge now to be lower than full charge.=20
Post by Miguel Ojeda
So, maybe the battery works as you suggested; still, the kernel shoul=
d
Post by Miguel Ojeda
provide a common meaning to its interfaces. If some batteries report
full_charge when in "charged" state and others report
design_full_charge, then the kernel should convert all of them into
one unique convention, or there is no sane way to write userspace
applications.
I still want to receive raw data from driver, and have 1 level of inter=
preters.
As I understand, there is HAL, which may do interpretations for you and=
keep it in single location.
Post by Miguel Ojeda
Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-06 17:05:13 UTC
Permalink
On Mon, Oct 5, 2009 at 2:18 AM, Alexey Starikovskiy
Post by Miguel Ojeda
On Mon, Oct 5, 2009 at 12:38 AM, Alexey Starikovskiy
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
This is not my rule, it was/is the rule of power device class. If=
you
Post by Miguel Ojeda
Post by Miguel Ojeda
Post by Alexey Starikovskiy
do
not
agree to it, please change
appropriate documentation.
Oh, I did not know that. Thank you for pointing it out. I think yo=
u
Post by Miguel Ojeda
Post by Miguel Ojeda
=9A158Q: Suppose, my battery monitoring chip/firmware does not pro=
vides
Post by Miguel Ojeda
Post by Miguel Ojeda
capacity
=9A159 =9A in percents, but provides charge_{now,full,empty}. Shou=
ld I
Post by Miguel Ojeda
Post by Miguel Ojeda
calculate
=9A160 =9A percentage capacity manually, inside the driver, and re=
gister
Post by Miguel Ojeda
Post by Miguel Ojeda
CAPACITY
=9A161 =9A attribute? The same question about time_to_empty/time_t=
o_full.
Post by Miguel Ojeda
Post by Miguel Ojeda
=9A162A: Most likely, no. This class is designed to export propert=
ies
Post by Miguel Ojeda
Post by Miguel Ojeda
which
are
=9A163 =9A directly measurable by the specific hardware available.
=9A164
=9A165 =9A Inferring not available properties using some heuristic=
s or
Post by Miguel Ojeda
Post by Miguel Ojeda
mathematical
=9A166 =9A model is not subject of work for a battery driver. Such
functionality
=9A167 =9A should be factored out, and in fact, apm_power, the dri=
ver to
Post by Miguel Ojeda
Post by Miguel Ojeda
serve
=9A168 =9A legacy APM API on top of power supply class, uses a sim=
ple
Post by Miguel Ojeda
Post by Miguel Ojeda
heuristic of
=9A169 =9A approximating remaining battery capacity based on its c=
harge,
Post by Miguel Ojeda
Post by Miguel Ojeda
current,
=9A170 =9A voltage and so on. But full-fledged battery model is li=
kely not
Post by Miguel Ojeda
Post by Miguel Ojeda
subject
=9A171 =9A for kernel at all, as it would require floating point c=
alculation
Post by Miguel Ojeda
Post by Miguel Ojeda
to deal
=9A172 =9A with things like differential equations and Kalman filt=
ers. This
Post by Miguel Ojeda
Post by Miguel Ojeda
is
=9A173 =9A better be handled by batteryd/libbattery, yet to be wri=
tten.
Post by Miguel Ojeda
Post by Miguel Ojeda
We are not calculating anything new just by the pleasure of doing =
it,
Post by Miguel Ojeda
Post by Miguel Ojeda
we are correcting a wrong value provided by the hardware.
You are guessing that normal battery can not jump charge value, and=
on
Post by Miguel Ojeda
this
assumption you
cap charge_now with last full_charge. Immediate problem is that
full_charge
is not fixed value,
this is why it is separated from design_full_charge.
During battery life full_charge may go down and up, depending on ou=
tside
Post by Miguel Ojeda
temperature, battery discharge (full or partial).
I've seen batteries on some new machines reporting full charge of m=
ore
Post by Miguel Ojeda
than
design charge.
Obviously, your patch will fail in some of the above situations.
I don't see why. The patch compares against full_charge every time
(which is updated as you say), not against design_full_charge.
1. full_charge > design_full_charge =3D> OK, design_full_charge is n=
ot
Post by Miguel Ojeda
involved in the min() operation.
2. full_charge goes down =3D> If charge_now > full_charge then hardw=
are
Post by Miguel Ojeda
is wrong and we should read full_charge. OK.
3. full_charge goes up =3D> Same.
full_charge_capacity is the value of last full charge. It will be upd=
ated to
current full charge, when the charging is complete. It may end up low=
er or
greater than
previous value.
Comparing current charge with the last full charge may correctly give=
you
Post by Miguel Ojeda
100%.
Then maybe we can write something like...

val->intval =3D acpi_battery_is_charged(battery)
? min(battery->capacity_now, battery->full_charge_capacity) * 1000
: battery->capacity_now * 1000;

So we only use the min() operation when it is fully charged (returning
to 100%) without losing information when charging.

The problem is that percentage may jump from >100% to 100% in
batteries whose full capacity increase, but I think that is OK, since
when completely charged, the >100% is the new 100%.

In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.

Still other special cases may appear. What do you think?
Now we have a decision to make -- do we update full charge to be grea=
ter
than charge now,
or do we update charge now to be lower than full charge.
Post by Miguel Ojeda
So, maybe the battery works as you suggested; still, the kernel shou=
ld
Post by Miguel Ojeda
provide a common meaning to its interfaces. If some batteries report
full_charge when in "charged" state and others report
design_full_charge, then the kernel should convert all of them into
one unique convention, or there is no sane way to write userspace
applications.
I still want to receive raw data from driver, and have 1 level of
interpreters.
As I understand, there is HAL, which may do interpretations for you a=
nd keep
it in single location.
AFAIK, the battery plugins I checked read /proc or /sys directly. I
will check other battery plugins too.
Post by Miguel Ojeda
Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pavel Machek
2009-10-10 12:04:48 UTC
Permalink
Hi!
Post by Miguel Ojeda
current full charge, when the charging is complete. It may end up lower or
greater than
previous value.
Comparing current charge with the last full charge may correctly give you
100%.
Then maybe we can write something like...
val->intval = acpi_battery_is_charged(battery)
? min(battery->capacity_now, battery->full_charge_capacity) * 1000
: battery->capacity_now * 1000;
So we only use the min() operation when it is fully charged (returning
to 100%) without losing information when charging.
The problem is that percentage may jump from >100% to 100% in
batteries whose full capacity increase, but I think that is OK, since
when completely charged, the >100% is the new 100%.
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.
I believe you better work around this in userspace... or agree that
Post by Miguel Ojeda
100% charge is possible.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Miguel Ojeda
2009-10-10 20:53:39 UTC
Permalink
Post by Pavel Machek
Hi!
Post by Miguel Ojeda
current full charge, when the charging is complete. It may end up =
lower or
Post by Pavel Machek
Post by Miguel Ojeda
greater than
previous value.
Comparing current charge with the last full charge may correctly g=
ive you
Post by Pavel Machek
Post by Miguel Ojeda
100%.
Then maybe we can write something like...
val->intval =3D acpi_battery_is_charged(battery)
=A0 =A0 =A0 ? min(battery->capacity_now, battery->full_charge_capaci=
ty) * 1000
Post by Pavel Machek
Post by Miguel Ojeda
=A0 =A0 =A0 : battery->capacity_now * 1000;
So we only use the min() operation when it is fully charged (returni=
ng
Post by Pavel Machek
Post by Miguel Ojeda
to 100%) without losing information when charging.
The problem is that percentage may jump from >100% to 100% in
batteries whose full capacity increase, but I think that is OK, sinc=
e
Post by Pavel Machek
Post by Miguel Ojeda
when completely charged, the >100% is the new 100%.
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.
I believe you better work around this in userspace... or agree that
Post by Miguel Ojeda
100% charge is possible.
I agree that >100% charge is possible while charging (because that
would mean the battery is over the last charged level); however, what
does it mean when charged?

In any case, my laptop's battery is not charging over 100% its
original capacity anyway, just reporting a wrong value.
Post by Pavel Machek
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pavel
Post by Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/hors=
es/blog.html
Pavel Machek
2009-10-10 21:25:21 UTC
Permalink
Hi!
Post by Miguel Ojeda
Post by Pavel Machek
Post by Miguel Ojeda
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.
I believe you better work around this in userspace... or agree that
Post by Miguel Ojeda
100% charge is possible.
I agree that >100% charge is possible while charging (because that
would mean the battery is over the last charged level); however, what
does it mean when charged?
Well, maybe the battery only updates full_charge_capacity during
powerdown or when the moon is full or something? (IOW you may be
breaking already working machines).
Post by Miguel Ojeda
In any case, my laptop's battery is not charging over 100% its
original capacity anyway, just reporting a wrong value.
True. But I do not think you are fixing it properly. Maybe ask for
fixed BIOS?

Or perhaps add quirk based on DMI or something?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-10 21:44:42 UTC
Permalink
Post by Pavel Machek
Hi!
Post by Miguel Ojeda
Post by Miguel Ojeda
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it wa=
s
Post by Pavel Machek
Post by Miguel Ojeda
Post by Miguel Ojeda
only present in the charged state.
I believe you better work around this in userspace... or agree tha=
t
Post by Pavel Machek
Post by Miguel Ojeda
Post by Miguel Ojeda
100% charge is possible.
I agree that >100% charge is possible while charging (because that
would mean the battery is over the last charged level); however, wha=
t
Post by Pavel Machek
Post by Miguel Ojeda
does it mean when charged?
Well, maybe the battery only updates full_charge_capacity during
powerdown or when the moon is full or something? (IOW you may be
breaking already working machines).
I do not know about batteries as I said, I was waiting for someone to
point out how batteries (normally/should) work.
Post by Pavel Machek
Post by Miguel Ojeda
In any case, my laptop's battery is not charging over 100% its
original capacity anyway, just reporting a wrong value.
True. But I do not think =A0you are fixing it properly. Maybe ask for
fixed BIOS?
Well, many BIOS/systems are broken and Linux has to workaround them. I
am sure there are a lot of broken batteries out there.
Post by Pavel Machek
Or perhaps add quirk based on DMI or something?
My battery is easily identified by its model name, so maybe we can
apply the workaround only to known hardware. Still, that is a "heavy"
solution, as I suppose there are many many battery models in the
world. That is why I was asking whether some kind of standard/unified
batteries' values/behavior exists (or implement it) that we can try to
achieve easily with some heuristics like the one I proposed, instead
of some kind of huge table-based workaround system.
Post by Pavel Machek
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
Pavel
Post by Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/hors=
es/blog.html
Pavel Machek
2009-10-10 22:49:58 UTC
Permalink
Post by Miguel Ojeda
Post by Pavel Machek
Hi!
Post by Miguel Ojeda
Post by Pavel Machek
Post by Miguel Ojeda
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.
I believe you better work around this in userspace... or agree that
Post by Miguel Ojeda
100% charge is possible.
I agree that >100% charge is possible while charging (because that
would mean the battery is over the last charged level); however, what
does it mean when charged?
Well, maybe the battery only updates full_charge_capacity during
powerdown or when the moon is full or something? (IOW you may be
breaking already working machines).
I do not know about batteries as I said, I was waiting for someone to
point out how batteries (normally/should) work.
Different batteries work very differently, I'm afraid.
Post by Miguel Ojeda
Post by Pavel Machek
Or perhaps add quirk based on DMI or something?
My battery is easily identified by its model name, so maybe we can
apply the workaround only to known hardware. Still, that is a "heavy"
solution, as I suppose there are many many battery models in the
world. That is why I was asking whether some kind of standard/unified
batteries' values/behavior exists (or implement it) that we can try to
achieve easily with some heuristics like the one I proposed, instead
of some kind of huge table-based workaround system.
The heuristics you proposed _will_ break other batteries, so it is not
acceptable without checking for model first.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Henrique de Moraes Holschuh
2009-10-10 21:52:24 UTC
Permalink
Post by Pavel Machek
Post by Miguel Ojeda
Post by Pavel Machek
Post by Miguel Ojeda
In "broken" batteries (is it broken finally? or is it expected
behaviour?) like mine the old problem will be corrected, as it was
only present in the charged state.
I believe you better work around this in userspace... or agree that
Post by Miguel Ojeda
100% charge is possible.
I agree that >100% charge is possible while charging (because that
would mean the battery is over the last charged level); however, what
does it mean when charged?
Well, maybe the battery only updates full_charge_capacity during
powerdown or when the moon is full or something? (IOW you may be
breaking already working machines).
Post by Miguel Ojeda
In any case, my laptop's battery is not charging over 100% its
original capacity anyway, just reporting a wrong value.
True. But I do not think you are fixing it properly. Maybe ask for
fixed BIOS?
Or perhaps add quirk based on DMI or something?
FIW, I do think we should attempt to fix situations that are always wrong,
we have a long history of doing that, and it doesn't make sense to send to
userspace stuff that we _know_ to be crap.

The problem is that to, e.g., fix last_full_capacity, you need to be able to
trust your reports of battery state (needs to be idle or discharging), and
current capacity.

So it ends up needing to be quirk-based, as different broken crap will fail
in conflicting ways, so you can't fix them all in one sweep, you'll just
make it worse. And the _one_ thing we must never do is to make it worse for
the hardware/firmware that gets it right...

I agree with Pavel, can you make it quirk-based?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki
2009-10-04 22:43:56 UTC
Permalink
Post by Alexey Starikovskiy
Hi Rafael,
Alex,
Post by Alexey Starikovskiy
This is not my rule, it was/is the rule of power device class. If you do not agree to it, please change
appropriate documentation.
I think we're talking about two different things. One thing is that we
shouldn't put any _arbitrary_ interpretation rules into the kernel, which I
agree with. The other one is that if there's a _known_ _broken_ hardware
and one possible way of handling it is to add a quirk into the kernel, we
should at least consider doing that.

In my opinion adding a quirk for a broken hardware is not equivalent to
"inferring not available properties using some heuristics or mathematical
model", if that's what you're referring to.

That said, the patch should not change the _default_ code in order to handle
the quirky hardware correctly. IMO, the quirky hardware should be recognized
during initialisation, if possible, and later handled in a special way. If
it's not possible to detect the broken hardware reliably, I agree that there's
nothing we can do about that in the kernel.

Thanks,
Rafael
Alexey Starikovskiy
2009-10-04 22:56:55 UTC
Permalink
Post by Alexey Starikovskiy
Hi Rafael,
=20
Alex,
=20
Post by Alexey Starikovskiy
This is not my rule, it was/is the rule of power device class. If yo=
u do not agree to it, please change
Post by Alexey Starikovskiy
appropriate documentation.
=20
I think we're talking about two different things. One thing is that =
we
shouldn't put any _arbitrary_ interpretation rules into the kernel, w=
hich I
agree with. The other one is that if there's a _known_ _broken_ hard=
ware
and one possible way of handling it is to add a quirk into the kernel=
, we
should at least consider doing that.
=20
In my opinion adding a quirk for a broken hardware is not equivalent =
to
"inferring not available properties using some heuristics or mathemat=
ical
model", if that's what you're referring to.
No, this is not a clear "bug" and not a clear "fix". Please read my rep=
ly to Miguel.
=20
That said, the patch should not change the _default_ code in order to=
handle
the quirky hardware correctly. IMO, the quirky hardware should be re=
cognized
It will change behaviour of at least Samsung notebooks, for which I per=
sonally saw the=20
charge_now/full_charge being greater then design_charge.
during initialisation, if possible, and later handled in a special wa=
y. If
it's not possible to detect the broken hardware reliably, I agree tha=
t there's
nothing we can do about that in the kernel.
I am still not sure if we have a broken hardware here.

Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-04 23:58:10 UTC
Permalink
On Mon, Oct 5, 2009 at 12:56 AM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Rafael,
Alex,
Post by Alexey Starikovskiy
This is not my rule, it was/is the rule of power device class. If y=
ou do
Post by Alexey Starikovskiy
not agree to it, please change
appropriate documentation.
I think we're talking about two different things. =C2=A0One thing is=
that we
shouldn't put any _arbitrary_ interpretation rules into the kernel, =
which
I
agree with. =C2=A0The other one is that if there's a _known_ _broken=
_ hardware
and one possible way of handling it is to add a quirk into the kerne=
l, we
should at least consider doing that.
In my opinion adding a quirk for a broken hardware is not equivalent=
to
"inferring not available properties using some heuristics or mathema=
tical
model", if that's what you're referring to.
No, this is not a clear "bug" and not a clear "fix". Please read my r=
eply to
Miguel.
That said, the patch should not change the _default_ code in order t=
o
handle
the quirky hardware correctly. =C2=A0IMO, the quirky hardware should=
be
recognized
It will change behaviour of at least Samsung notebooks, for which I
personally saw the charge_now/full_charge being greater then design_c=
harge.
during initialisation, if possible, and later handled in a special w=
ay.
=C2=A0If
it's not possible to detect the broken hardware reliably, I agree th=
at
there's
nothing we can do about that in the kernel.
I am still not sure if we have a broken hardware here.
I have no idea about batteries, but jumping from 5950 mAh to 7650 mAh
within one second does not seem non-broken to me. ;)
Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Miguel Ojeda
2009-10-04 21:42:51 UTC
Permalink
On Sun, Oct 4, 2009 at 8:57 PM, Alexey Starikovskiy
Post by Alexey Starikovskiy
Hi Miguel,
I am going to reject your patch on the basis, that the battery driver=
should
Post by Alexey Starikovskiy
report only
information it gained from battery hardware, not interpret it in any =
way.
Post by Alexey Starikovskiy
As your patch fall into "interpret" category, it does not belong in t=
he
Post by Alexey Starikovskiy
kernel and battery
driver in particular. You may suggest it to any/all user space batter=
y
Post by Alexey Starikovskiy
monitoring applications,
this is the place for "interpretations".
I understand your point. However, there are other parts in the same
file that need to do "interpretation", for example:

http://lxr.linux.no/linux+*/drivers/acpi/battery.c#L157

157 /* fallback to using design values for broken batteries */
158 if (battery->design_capacity =3D=3D battery->capacity_now)
159 return 1;

I agree with Rafael, the kernel must interpret the hardware as best as
possible (it is its job, isn't it?). In countless places the kernel
has to "fix" (workaround) hardware bugs in order to present userspace
a unified interface, correct values, etc.

In this case my battery is reporting a obvious wrong value that causes
(apparently) correct userspace applications to misbehave.

Maybe the patch I proposed is not the correct solution; however, the
bug remains.
Post by Alexey Starikovskiy
Not-acknowledged-by: Alexey Starikovskiy
Regards,
Alex.
Post by Miguel Ojeda
On Sun, Oct 4, 2009 at 6:45 PM, Henrique de Moraes Holschuh
Some broken batteries like my DELL NR2227 or a friend's DELL GK479=
8
Post by Alexey Starikovskiy
Post by Miguel Ojeda
return
the design_capacity (charge_full_design) as capacity_now (charge_n=
ow)
Post by Alexey Starikovskiy
Post by Miguel Ojeda
when completely charged.
I noticed this when looking at a battery plugin that reported "127=
%
Post by Alexey Starikovskiy
Post by Miguel Ojeda
charged".
Some of these plugins have already "fixed" this in userspace by co=
ding
Post by Alexey Starikovskiy
Post by Miguel Ojeda
something like min(percentage, 100)).
A battery can be charged above 100%. =C2=A0It just depends what you=
call 100%,
Post by Alexey Starikovskiy
Post by Miguel Ojeda
and the "I am full" level *varies* in a non-monotonic way during th=
e
Post by Alexey Starikovskiy
Post by Miguel Ojeda
battery
lifetime...
So, if you don't want to see > 100%, you have to clamp it to 100% a=
nd
Post by Alexey Starikovskiy
Post by Miguel Ojeda
lose
information (when your "100%" level is actually increasing as the t=
hing
Post by Alexey Starikovskiy
Post by Miguel Ojeda
keeps charging and you keep raising the baseline so that it doesn't=
go
Post by Alexey Starikovskiy
Post by Miguel Ojeda
over
100%).
If the 100% level increased, then full_charge_capacity (a.k.a. "_las=
t_
Post by Alexey Starikovskiy
Post by Miguel Ojeda
full capacity" as seen in /proc) will increase as well, won't it? If
the battery went over that 100% that means there is a "new" 100%, wh=
y
Post by Alexey Starikovskiy
Post by Miguel Ojeda
are we losing information?.
I am asking, I am not an expert on battery stuff.
So I discovered that the battery wrongly returns charge_full_desig=
n when
Post by Alexey Starikovskiy
Post by Miguel Ojeda
completely charged instead of charge_full.
Ick.
This patch fixes this by returning min(capacity_now,
full_charge_capacity)
on both procfs and sysfs.
What will it cause on non-broken batteries? =C2=A0Or during gauge r=
eset, when
Post by Alexey Starikovskiy
Post by Miguel Ojeda
any
battery that updates full_charge_capacity only at the end of the cy=
cle
Post by Alexey Starikovskiy
Post by Miguel Ojeda
will
really have capacity_now > full_charge_capacity ?
Well, does it make sense to have capacity_now higher than
full_charge_capacity? Wouldn't that information be broken too?
Again, I am just wondering.
Now the userspace plugins report the correct 100% and their usersp=
ace
Post by Alexey Starikovskiy
Post by Miguel Ojeda
check
may not be needed (if this error is the only one producing >100% results).
Like I said, > 100% can happen, unless what you define to be 100% i=
s very
Post by Alexey Starikovskiy
Post by Miguel Ojeda
elastic (and gets updated all the time).
I still think it does not make sense to have a battery charged over
its 100% capacity whatever the definition of 100% is. Maybe I do not
understand your point.
--
=C2=A0"One disk to rule them all, One disk to find them. One disk t=
o bring
Post by Alexey Starikovskiy
Post by Miguel Ojeda
=C2=A0them all and in the darkness grind them. In the Land of Redmo=
nd
Post by Alexey Starikovskiy
Post by Miguel Ojeda
=C2=A0where the shadows lie." -- The Silicon Valley Tarot
=C2=A0Henrique Holschuh
Continue reading on narkive:
Loading...