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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 26 Nov 2021 14:35:18 +0200
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     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>,
        "Mutanen, Mikko" <Mikko.Mutanen@...rohmeurope.com>
Subject: Re: [RFC PATCH v3 3/9] power: supply: Support DT originated
 temperature-capacity tables

On 11/26/21 13:56, Vaittinen, Matti wrote:
> 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 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.

After reading what I wrote even I didn't know what I tried to say. Well, 
I think I tried to explain that I don't see how we can use this 
information to do any estimation what the Coulomb Counter reading 
represent at the given temperature. This is what the 
temperature-degradation tables aim to give us.

  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.

I think I tried to say that these curves don't help us to tell how many 
uAhs we have in battery with different temperatures when battery is 
empty, or half full or, ... Again, what we would like to know is what 
SOC our CC value represents - and use OCV to just adjust this further 
(or in some cases to correct the CC value using OCV - if we can trust 
the battery to be properly relaxed).

Hope this did clarify. Afraid it didn't :)

Best Regards
	-- Matti Vaittinen