linux-kernel - Re: [PATCH] power_supply: support CHARGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 08 May 2008 16:44:43 -0400
From:	"Richard A. Smith" <richard@...top.org>
To:	avorontsov@...mvista.com
CC:	Andres Salomon <dilinger@...ued.net>,
	Andrew Morton <akpm@...ux-foundation.org>, cbou@...l.ru,
	linux-kernel@...r.kernel.org, dwmw2@...radead.org
Subject: Re: [PATCH] power_supply: support CHARGE_NOW in OLPC battery

Anton Vorontsov wrote:

> Cool, I believe this is exactly same thing as we have on DS2760. ACR
> counts up and down. For example, if there was a current of 10 uA for
> 30 minutes, ACR will show 5 uAh. Additional 30 minutes with current
> -10 uA will result in 0 uAh in ACR... Right?

Yes. Exactly correct.

>> The units for the ACR register in the DS2765 are:
> 
> Do you have any specs for the ds2765? I'd like to see one, if
> it isn't restricted matter. google:ds2765 pdf wasn't helpful...
> 

Ooop.  Sorry my typo.  DS2756.

http://wiki.laptop.org/images/e/e9/DS2756.pdf
or
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/5104

>> 6.25 uVh / Rsense
>> OLPC Rsense = .015 Ohms
>>
>> The integer math conversion for ACR to mAh that I use in my scripts is:
>>
>> (ACR2 - ACR1) * 625 / 1500
> 
> Just curious.. What does the final value mean and how do you use it?
> ACR is the Ah counter. You're subtracting one from another, and that
> value will show you.. difference of Ah between T2 and T1..?
> 
> You'll get something useful (current) if you divide the value by T2-T1
> though... ;-) But I believe OLPC can report current by itself...

There is no final value. Only relative values.  The EC can detect the 
ends of the spectrum.  Battery empty and battery full.  At those 
endpoints it sets the SOC% to x% (exact x varies depending on the 
battery type) But lets use full and 90% as the example.

So you charge the battery until the criteria for a full battery are met 
and then you set the SOC% to 90%.  This value is stored in the EEPROM of 
the DS2756.   So then when the EC senses that the battery is discharging 
it monitors the relative ACR change.  It uses that to compute how much % 
loss and updates the SOC%.  If you are partially discharged and Ext 
power is provided so that the battery begins to charge then the reverse 
happens.  The absolute value of the ACR is never used. Only the 
difference.  The corrections of any errors happen when the full or empty 
conditions are met.

>> Is CHARGE_NOW supposed to be an absolute indication of the level of  
>> charge in the battery?  If so then thats not ACR.
> 
> This depends. On DS2760 ACR is the only way to determine battery's
> "charge" at the given time (thus the capacity in percents, since ds2760
> can't report it).

Ours is the same way.  The EC just does the extra work to keep an SOC% 
value.

> It needs calibration though... ds2760_battery.c doing this: resetting the
> ACR to CHARGE_FULL value when battery is in charging state with current
> flow < 10 mA.
> 
> Works quite good here.

Ah.. I see now.  You are using the ACR directly as the SOC value. 
Whereas OLPC does not.

If your battery capacity stays reasonably constant across the operating 
temp range then I see how that would work fine.  With NiMh chemistry the 
capacity changes quite a bit wrt temperature. Li chemistries capacity 
are much less temp sensitive.

I can't say for certain because I didn't do the original code design but 
from what I see in the EC code it tries to compensate for that capacity 
change when using NiMh.  So they record the net ACR change and use that 
to try and compute the real SOC% change.  I suppose you could still make 
it work with just the ACR register but thats not how Quanta chose to do 
the implementation.

>> That would be SOC% *  
>> battery capacity.  The EC uses the relative motion of the ACR to update  
>> the SOC%.
> 
> Since you don't seem to use ACR as CHARGE_NOW, I think maybe we indeed
> should implement PROP_ACR or better PROP_CHARGE_COUNTER? With units of
> uAh... would that work?

That would work fine.

-- 
Richard Smith  <richard@...top.org>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/