[PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

[Richard A. Smith]

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

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%) [1].

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.

http://wiki.laptop.org/go/Laptop_Batteries

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)


[1]  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