[PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
Richard A. Smith
richard at laptop.org
Fri Dec 10 23:37:35 EST 2010
On 12/10/2010 10:22 PM, Andres Salomon wrote:
> Alright, thanks. I guess a comment in the (kernel) source saying as
> much would be useful.
> On Fri, 10 Dec 2010 21:41:00 -0500 Paul Fox<pgf at laptop.org> wrote:
>> i'm pretty sure those numbers (and the corresponding numbers from the
>> 1.5 DSDT) came from the battery manufacturer. obviously we could move
>> the data to the EC, but i'm not sure what the advantage of that would
>> be. i know that the numbers don't come from the battery itself.
Some history for those who may not know:
The design of the battery system in the EC is sort of out in its own
class. OLPC sort of forced that to happen.
1) We used battery chemistry's few laptop have used and used both of
them at the same time. NiMH and LiFePO4. (In the LiFePO4 case, I think
we are the only laptop that has used it.)
2) In XO-1 we had the "We hate the evil ACPI mantra".
To top it off we had this requirement of the battery lasting 2000
cycles. This requires some very funky stuff in the NiMH case.
Basically for NiMH there is a really complex 12 page flowchart on
charging. We have now stopped caring about NiMH but the 1.0 and 1.5
carry around a lot of legacy NiMH baggage. In 1.75 we have purged all
We had (good) reasons for doing all of the above but we basically forced
quanta to come up with a battery subsystem on their own. Not one that
followed any of the accepted standards at the time.
The system that they came up with does not have any concept of battery
capacity. It uses markers inherent in the battery characteristics to
determine when the battery is full and empty. To track the state of
charge (SOC) each chemistry has a setting for what the net difference
for 1% SOC is in the accumulated current register (ACR). If the ACR
goes up or down that value then the SOC is ++ or -- 1%. The ACR is used
as a free running counter of charge. When a full or empty marker is
found the SOC is snapped to a full (97%) or empty (7%) .
So none of the max capacity values that you are asking about exist in
the EC because they aren't necessary for things to work. All the values
about max capacity are values that I pulled from the manufactures
datasheet and put up on the wiki.
Until now there hasn't been a reason to add this info into the EC code.
There is nothing hard about adding them except that its a few more
commands for the EC, OFW, and kernel to add and then all be in sync.
There's also no concept of calibration in the EC code. Last time Sascha
brought all this up I began to think about how to do some sort of
calibration. It would be a nice feature to have. We already have a
some issues because the battery capacity varies +/- 5%. If I had
calibration then I could store the "real" capacity in the eeprom of the
battery. Hopefully I can get a chance to figure out a good way to do
this for 1.75 and keep it so that batteries are backward compatible. in
1.5 and 1.0
If you want the max capacity values added to the EC code with EC
commands to fetch that extra the data then that's not a big problem just
tell me. But that won't help with running your new kernel on an old XO
with older firmware so you will still have to hardcode it for them.
I think it makes sense to hardcode them until such time as I have
calibration in the EC code and then the kernel can ask the EC (or OFW
via DT for them)
 I have no idea where those values came from. I'm changing them in
1.75 to be more sane.
Richard A. Smith <richard at laptop.org>
One Laptop per Child
More information about the Devel