linux-kernel - Re: [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables

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:   Fri, 26 Nov 2021 11:56:37 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Matti Vaittinen <mazziesaccount@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        "rostokus@...il.com" <rostokus@...il.com>,
        "fan.chen@...iatek.com" <fan.chen@...iatek.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-power <linux-power@...rohmeurope.com>
Subject: Re: [RFC PATCH v3 3/9] power: supply: Support DT originated
 temperature-capacity tables

Hi dee Ho again,

On 11/18/21 08:11, Matti Vaittinen wrote:
> Hi Linus,
> 
> On 11/18/21 04:10, Linus Walleij wrote:
>> On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
>> <matti.vaittinen@...rohmeurope.com> wrote:
>>
>>> Support obtaining the "capacity degradation by temperature" - tables
>>> from device-tree to batinfo.
>>>
>>> Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
>>
>> Same questions as on the binding patch.
>>
>> If we already support different degradation by temperature tables,
>> why do we need a second mechanism for the same thing?
> 
> Thanks for bringing this up. As I said, I didn't notice that we could 
> indeed use the CAP-OCV tables for different temperatures to bring in 
> this information :) I see certain benefit from the possibility of not 
> requiring to measure the OCV at different temperatures - but it may not 
> be meaningful. As I replied to your patch 1/9 review - I need to (try 
> to) do some more research...

I tried doing some pondering here today. Unfortunately, the Friday 
afternoon is probably the worst time to try this - my brains cease 
operating at the afternoon - and double so at the Friday. Friday 
afternoons are good for babbling via email though ;)

I don't see providing OCV tables at different temperature gives the 
degradation of battery capacity. Whoah. A big thought for Friday.

We get the OCV => SOC correspondance at different temperatures. I 
however don't see how this gives the OCV => energy relation. As far as I 
know both the OCV and the 'amount of uAhs battery is able to store' are 
impacted by temperature change. This means, seeing the OCV => SOC at 
different temperatures does not tell us what is the impact of 
temperature to the OCV, and what is the impact to SOC.

For cases like the ROHM Chargers, we are interested on how much has the 
'ability to store uAhs' changed due to the temperature. When we know the 
amount of uAhs we can store, we can use the coulomb counter value to 
estimate what we still have left in the battery.

In addition to this we do use the OCV information for the "nearly 
depleted battery" - to improve the estimation by zero-correction 
algorithm. I must admit Friday afternoon is not the time I can quite 
recap this part. I think it was something like:

1. Measure VBat with system load (VBAT)
2. Find OCV corresponding the current SOC estimate (SOC based on coulomb 
counter value) - OCV_NOW
3. Compute VDROP caused by the load (OCV_NOW - VBAT)
4. Assume VDROP stays constant (or use ROHM VDR parameters if provided)
5. Using VDROP compute the OCV_MIN which matches the minimum battery 
voltage where system is still operational
6. Use the OCV_MIN and "OCV at SOC0 from calibration data" difference to 
adjust the battery capacity.

(Explanation done at Friday afternoon accuracy here).

>> I'd just calculate a few tables per temperature and be done with
>> it.
>>
>> At least documentation needs to be updated to reflect that the two 
>> methods
>> are exclusive and you can only use one of them.

I don't see these exclusive (at Friday afternoon at least). I think they 
can complement each-others. The temp_degradation table gives us the 
temperature impact on <energy storing ability>, eg, how much the battery 
capacity has changed from designed one due to the temperature.

OCV-SOC tables at various temperatures tell us how OCV looks like when 
we have X% of battery left at different temperatures. Estimation of how 
much the X% is in absolute uAhs can be done by taking into account the 
designed_cap, aging degradation and the temperature degradation (and the 
position of moon, amount of muons created by cosmic rays hitting 
athmosphere at knee energy region and so on...)

Or am I just getting something terribly wrong (again)? :)
(I still for example like internal functions named as __foo() )

Yours
--Matti

-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~