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<p...@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 <rich...@laptop.org> One Laptop per Child _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel